Skip to content

G
git

李少辉-开发者 / git
与 Fork 源项目一致

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 20 8月, 2010 1 次提交
  3. 19 8月, 2010 18 次提交
  5. 18 8月, 2010 1 次提交
    • D
      mergetool: Skip autoresolved paths · bb0a484e
      由 David Aguilar 提交于 
      When mergetool is run without path limiters it loops
over each entry in 'git ls-files -u'.  This includes
autoresolved paths.

Teach mergetool to only merge files listed in 'rerere status'
when rerere is enabled.

There are some subtle but harmless changes in behavior.
We now call cd_to_toplevel when no paths are given.
We do this because 'rerere status' paths are always relative
to the root.  This is beneficial for the non-rerere use as
well in that mergetool now runs against all unmerged files
regardless of the current directory.

This also slightly tweaks the output when run without paths
to be more readable.

The old output:

Merging the files: foo
bar
baz

The new output:

Merging:
foo
bar
baz
Signed-off-by: NDavid Aguilar <davvid@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      bb0a484e
  7. 16 8月, 2010 3 次提交
    • Æ
      log: test for regression introduced in v1.7.2-rc0~103^2~2 · 65113121
      由 Ævar Arnfjörð Bjarmason 提交于 
      Add a regression test for the git log -M --follow $diff_option bug
introduced in v1.7.2-rc0~103^2~2, $diff_option being diff related
options like -p, --stat, --name-only etc.
Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      65113121
    • D
      git-svn: fix fetch with deleted tag · 3235b705
      由 David D. Kilzer 提交于 
      Currently git-svn assumes that two tags created from the same
revision will have the same repo url, so it uses a ref to the
tag without checking that its url matches the current url.

This causes issues when fetching an svn repo where a tag was
created, deleted, and then recreated under the following
circumstances:

- Both tags were copied from the same revision.
- Both tags had the same name.
- Both tags had different repository paths.
- [Optional] Both tags have a file with the same name but
  different content.

When all four conditions are met, a checksum mismatch error
occurs because the content of two files with the same path
differs (see t/t9155--git-svn-fetch-deleted-tag.sh):

    Checksum mismatch: ChangeLog 065854....
    expected: ce771b....
         got: 9563fd....

When only the first three conditions are met, no error occurs
but the tag in git matches the first (deleted) tag instead of
the last (most recent) tag (see
t/t9156-git-svn-fetch-deleted-tag-2.sh).

The fix is to verify that the repo url for the ref matches the
current url.  If the urls do not match, then a "tail" is grown
on the tag name by appending a dash and rechecking the new ref's
repo url until either a matching repo url is found or a new tag
is created.
Signed-off-by: NDavid D. Kilzer <ddkilzer@kilzer.net>
Acked-by: NEric Wong <normalperson@yhbt.net>
      3235b705
    • D
      git-svn: fix regex to remove "tail" from svn tags · 54fb7f9b
      由 David D. Kilzer 提交于 
      Fix a regular expression used to remove the revision from the
end of an svn tag or branch name.  The regex did not account for
any "tail" (dashes) that may have been added to the end of the
tag name (which first appeared in v1.4.1-rc2~11).  If not fixed,
tags with names like "tags/mytag@5--@2" may be created.
Signed-off-by: NDavid D. Kilzer <ddkilzer@kilzer.net>
Acked-by: NEric Wong <normalperson@yhbt.net>
      54fb7f9b
  9. 14 8月, 2010 2 次提交
    • J
      diff --follow: do call diffcore_std() as necessary · 44c48a90
      由 Junio C Hamano 提交于 
      Usually, diff frontends populate the output queue with filepairs without
any rename information and call diffcore_std() to sort the renames out.
When --follow is in effect, however, diff-tree family of frontend has a
hack that looks like this:

    diff-tree frontend
    -> diff_tree_sha1()
       . populate diff_queued_diff
       . if --follow is in effect and there is only one change that
         creates the target path, then
       -> try_to_follow_renames()
	  -> diff_tree_sha1() with no pathspec but with -C
	  -> diffcore_std() to find renames
	  . if rename is found, tweak diff_queued_diff and put a
	    single filepair that records the found rename there
    -> diffcore_std()
       . tweak elements on diff_queued_diff by
       - rename detection
       - path ordering
       - pickaxe filtering

We need to skip parts of the second call to diffcore_std() that is related
to rename detection, and do so only when try_to_follow_renames() did find
a rename.  Earlier 1da6175d (Make diffcore_std only can run once before a
diff_flush, 2010-05-06) tried to deal with this issue incorrectly; it
unconditionally disabled any second call to diffcore_std().

This hopefully fixes the breakage.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      44c48a90
    • J
      diff --follow: do not waste cycles while recursing · 39f75d26
      由 Junio C Hamano 提交于 
      The "--follow" logic is called from diff_tree_sha1() function, but the
input trees to diff_tree_sha1() are not necessarily the top-level trees
(compare_tree_entry() calls it while it recursively descends into
subtrees).  When a newly created path lives in somewhere deep in the
source hierarchy, e.g. "platform/", but the rename source is in a totally
different place in the destination hierarchy, e.g. "lang-api/src/com/...",
running "try_to_find_renames()" while base is set to "platform/" is a
wasted call.

We only need to run the rename following at the very top level.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      39f75d26
  11. 13 8月, 2010 12 次提交
  13. 12 8月, 2010 3 次提交