Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 02 9月, 2010 2 次提交
  3. 30 8月, 2010 2 次提交
  5. 27 8月, 2010 1 次提交
  7. 26 8月, 2010 2 次提交
    • E
      tree-walk: Correct bitrotted comment about tree_entry() · 2244eab0
      由 Elijah Newren 提交于 
      There was a code comment that referred to the "above two functions" but
over time the functions immediately preceding the comment have changed.
Just mention the relevant functions by name.
Signed-off-by: NElijah Newren <newren@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      2244eab0
    • L
      Fix 'git log' early pager startup error case · 1fda91b5
      由 Linus Torvalds 提交于 
      We start the pager too early for several git commands, which results in
the errors sometimes going to the pager rather than show up as errors.

This is often hidden by the fact that we pass in '-X' to less by default,
which causes 'less' to exit for small output, but if you do

  export LESS=-S

you can then clearly see the problem by doing

  git log --prretty

which shows the error message ("fatal: unrecognized argument: --prretty")
being sent to the pager.

This happens for pretty much all git commands that use USE_PAGER, and then
check arguments separately. But "git diff" does it too early too (even
though it does an explicit setup_pager() call)

This only fixes it for the trivial "git log" family case.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      1fda91b5
  9. 25 8月, 2010 2 次提交
  11. 23 8月, 2010 1 次提交
  13. 22 8月, 2010 2 次提交
  15. 21 8月, 2010 9 次提交
  17. 20 8月, 2010 3 次提交
  19. 19 8月, 2010 2 次提交
  21. 16 8月, 2010 1 次提交
  23. 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
  25. 13 8月, 2010 6 次提交
    • E
      pull --rebase: Avoid spurious conflicts and reapplying unnecessary patches · cf65426d
      由 Elijah Newren 提交于 
      Prior to c85c7927 (pull --rebase: be cleverer with rebased upstream
branches, 2008-01-26), pull --rebase would run

  git rebase $merge_head

which resulted in a call to

  git format-patch ... --ignore-if-in-upstream $merge_head..$cur_branch

This resulted in patches from $merge_head..$cur_branch being applied, as
long as they did not already exist in $cur_branch..$merge_head.

Unfortunately, when upstream is rebased, $merge_head..$cur_branch also
refers to "old" commits that have already been rebased upstream, meaning
that many patches that were already fixed upstream would be reapplied.
This could result in many spurious conflicts, as well as reintroduce
patches that were intentionally dropped upstream.

So the algorithm was changed in c85c7927 (pull --rebase: be cleverer with
rebased upstream branches, 2008-01-26) and d44e7126 (pull: support rebased
upstream + fetch + pull --rebase, 2009-07-19).  Defining $old_remote_ref to
be the most recent entry in the reflog for @{upstream} that is an ancestor
of $cur_branch, pull --rebase was changed to run

  git rebase --onto $merge_head $old_remote_ref

which results in a call to

  git format-patch ... --ignore-if-in-upstream $old_remote_ref..$cur_branch

The whole point of this change was to reduce the number of commits being
reapplied, by avoiding commits that upstream already has or had.

In the rebased upstream case, this change achieved that purpose.  It is
worth noting, though, that since $old_remote_ref is always an ancestor of
$cur_branch (by its definition), format-patch will not know what upstream
is and thus will not be able to determine if any patches are already
upstream; they will all be reapplied.

In the non-rebased upstream case, this new form is usually the same as the
original code but in some cases $old_remote_ref can be an ancestor of

   $(git merge-base $merge_head $cur_branch)

meaning that instead of avoiding reapplying commits that upstream already
has, it actually includes more such commits.  Combined with the fact that
format-patch can no longer detect commits that are already upstream (since
it is no longer told what upstream is), results in lots of confusion for
users (e.g. "git is giving me lots of conflicts in stuff I didn't even
change since my last push.")

Cases where additional commits could be reapplied include forking from a
commit other than the tracking branch, or amending/rebasing after pushing.
Cases where the inability to detect upstreamed commits cause problems
include independent discovery of a fix and having your patches get
upstreamed by some alternative route (e.g. pulling your changes to a third
machine, pushing from there, and then going back to your original machine
and trying to pull --rebase).

Fix the non-rebased upstream case by ignoring $old_remote_ref whenever it
is contained in $(git merge-base $merge_head $cur_branch).  This should
have no affect on the rebased upstream case.
Acked-by: NSanti Béjar <santi@agolina.net>
Signed-off-by: NElijah Newren <newren@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      cf65426d
    • E
      t5520-pull: Add testcases showing spurious conflicts from git pull --rebase · 3cee9236
      由 Elijah Newren 提交于 
      Signed-off-by: NElijah Newren <newren@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      3cee9236
    • M
      push: mention "git pull" in error message for non-fast forwards · 452c6d50
      由 Matthieu Moy 提交于 
      The message remains fuzzy to include "git pull", "git pull --rebase" and
others, but directs the user to the simplest solution in the vast
majority of cases.
Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      452c6d50
    • J
      Standardize do { ... } while (0) style · 98746061
      由 Jonathan Nieder 提交于 
      Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      98746061
    • B
      t/t7003: replace \t with literal tab in sed expression · 0d1d6e50
      由 Brandon Casey 提交于 
      The sed utilities on IRIX and Solaris do not interpret the sequence '\t'
to mean a tab character;  they read a literal character 't'.  So, use a
literal tab instead.
Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      0d1d6e50
    • N
      index-pack: Don't follow replace refs. · 6e2a09d2
      由 Nelson Elhage 提交于 
      Without this, attempting to index a pack containing objects that have been
replaced results in a fatal error that looks like:

fatal: SHA1 COLLISION FOUND WITH <replaced-object> !
Signed-off-by: NNelson Elhage <nelhage@ksplice.com>
Acked-by: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      6e2a09d2
  27. 12 8月, 2010 5 次提交