1. 25 Sep, 2014 2 commits
  2. 29 Aug, 2014 3 commits
  3. 26 Aug, 2014 3 commits
  4. 25 Aug, 2014 1 commit
    • Junio C Hamano's avatar
      Merge git://github.com/git-l10n/git-po · c285171d
      Junio C Hamano authored
      * git://github.com/git-l10n/git-po:
        l10n: de.po: improve message when switching branches
        l10n: de.po: fix typo
        po/TEAMS: Add Catalan team
        l10n: Add Catalan translation
        l10n: fr.po (2257t) update for version 2.1.0
        l10n: sv.po: Update Swedish translation (2257t0f0u)
        l10n: vi.po (2257t): Update translation
        l10n: Updated Bulgarian translation of git (2257t,0f,0u)
        l10n: zh_CN: translations for git v2.1.0-rc0
        l10n: git.pot: v2.1.0 round 1 (38 new, 9 removed)
        l10n: Updated Bulgarian translation of git (2247t,0f,0u)
        l10n: Updated Bulgarian translation of git (2228t,0f,0u)
        l10n: Fix more typos in the Swedish translations
  5. 23 Aug, 2014 4 commits
  6. 20 Aug, 2014 1 commit
    • Jeff King's avatar
      intersect_paths: respect mode in git's tree-sort · e09867f0
      Jeff King authored
      When we do a combined diff, we individually diff against
      each parent, and then use intersect_paths to do a parallel
      walk through the sorted results and come up with a final
      list of interesting paths.
      The sort order here is that returned by the diffs, which
      means it is in git's tree-order which sorts sub-trees as if
      their paths have "/" at the end. When we do our parallel
      walk, we need to use a comparison function which provides
      the same order.
      Since 8518ff8f (combine-diff: optimize combine_diff_path sets
      intersection, 2014-01-20), we use a simple strcmp to
      compare the pathnames, and get this wrong. It's somewhat
      hard to trigger because normally a diff does not produce
      tree entries at all, and therefore the sort order is the
      same as a strcmp. However, if the "-t" option is used with
      the diff, then we will produce diff_filepairs for both trees
      and files.
      We can use base_name_compare to do the comparison, just as
      the tree-diff code does. Even though what we have are not
      technically base names (they are full paths within the
      tree), the end result is the same (we do not care about
      interior slashes at all, only about the final character).
      However, since we do not have the length of each path
      stored, we take a slight shortcut: if neither of the entries
      is a sub-tree then the comparison is equivalent to a strcmp.
      This lets us skip the extra strlen calls in the common case
      without having to reimplement base_name_compare from
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  7. 19 Aug, 2014 1 commit
  8. 15 Aug, 2014 1 commit
  9. 13 Aug, 2014 1 commit
    • Johannes Sixt's avatar
      tests: fix negated test_i18ngrep calls · 41ca19b6
      Johannes Sixt authored
      The helper function test_i18ngrep pretends that it found the expected
      results when it is running under GETTEXT_POISON. For this reason, it must
      not be used negated like so
         ! test_i18ngrep foo bar
      because the test case would fail under GETTEXT_POISON. The function offers
      a special syntax to test that a pattern is *not* found:
         test_i18ngrep ! foo bar
      Convert incorrect uses to this syntax.
      Signed-off-by: default avatarJohannes Sixt <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  10. 12 Aug, 2014 1 commit
    • Jeff King's avatar
      pack-objects: turn off bitmaps when we see --shallow lines · f7f91086
      Jeff King authored
      Reachability bitmaps do not work with shallow operations,
      because they cache a view of the object reachability that
      represents the true objects. Whereas a shallow repository
      (or a shallow operation in a repository) is inherently
      cutting off the object graph with a graft.
      We explicitly disallow the use of bitmaps in shallow
      repositories by checking is_repository_shallow(), and we
      should continue to do that. However, we also want to
      disallow bitmaps when we are serving a fetch to a shallow
      client, since we momentarily take on their grafted view of
      the world.
      It used to be enough to call is_repository_shallow at the
      start of pack-objects.  Upload-pack wrote the other side's
      shallow state to a temporary file and pointed the whole
      pack-objects process at this state with "git --shallow-file",
      and from the perspective of pack-objects, we really were
      in a shallow repo.  But since b790e0f6 (upload-pack: send
      shallow info over stdin to pack-objects, 2014-03-11), we do
      it differently: we send --shallow lines to pack-objects over
      stdin, and it registers them itself.
      This means that our is_repository_shallow check is way too
      early (we have not been told about the shallowness yet), and
      that it is insufficient (calling is_repository_shallow is
      not enough, as the shallow grafts we register do not change
      its return value). Instead, we can just turn off bitmaps
      explicitly when we see these lines.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  11. 10 Aug, 2014 1 commit
  12. 08 Aug, 2014 3 commits
  13. 07 Aug, 2014 4 commits
  14. 05 Aug, 2014 5 commits
  15. 04 Aug, 2014 8 commits
  16. 03 Aug, 2014 1 commit