user/sven/git.git/git-pull.sh, branch v1.7.3.5

Merge branch 'en/rebase-against-rebase-fix'

2010-08-22T06:27:29Z

* en/rebase-against-rebase-fix: pull --rebase: Avoid spurious conflicts and reapplying unnecessary patches t5520-pull: Add testcases showing spurious conflicts from git pull --rebase

pull --rebase: Avoid spurious conflicts and reapplying unnecessary patches

2010-08-13T04:23:23Z

Prior to c85c792 (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 c85c792 (pull --rebase: be cleverer with rebased upstream branches, 2008-01-26) and d44e712 (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: Santi Béjar Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

pull: do nothing on --dry-run

2010-05-25T17:49:54Z

Pull was never meant to take --dry-run at all. However, it passes unknown arguments to git-fetch, which does do a dry-run. Unfortunately, pull then attempts to merge whatever cruft was in FETCH_HEAD (which the dry-run fetch will not have written to). Even though we never advertise --dry-run as something that should work, it is still worth being defensive because: 1. Other commands (including fetch) take --dry-run, so a user might try it. 2. Rather than simply producing an error, it actually changes the repository in totally unexpected ways. This patch makes "pull --dry-run" equivalent to "fetch --dry-run". Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'maint'

2010-03-20T18:29:19Z

* maint: Update draft release notes to 1.7.0.3 fetch: Fix minor memory leak fetch: Future-proof initialization of a refspec on stack fetch: Check for a "^{}" suffix with suffixcmp() daemon: parse_host_and_port SIGSEGV if port is specified Makefile: Fix CDPATH problem pull: replace unnecessary sed invocation

pull: replace unnecessary sed invocation

2010-03-20T14:25:02Z

Getting the shortened branch name is as easy as using the shell's parameter expansion. Signed-off-by: Stephen Boyd Signed-off-by: Junio C Hamano

fetch and pull: learn --progress

2010-02-24T16:35:45Z

Note that in the documentation for git-pull, documentation for the --progress option is displayed under the "Options related to fetching" subtitle via fetch-options.txt. Also, update the documentation of the -q/--quiet option for git-pull to mention its effect on progress reporting during fetching. Signed-off-by: Tay Ray Chuan Signed-off-by: Junio C Hamano

pull: re-fix command line generation

2010-01-24T18:11:27Z

14e5d40 (pull: Fix parsing of -X

Merge branch 'ap/merge-backend-opts'

2010-01-21T04:28:50Z

* ap/merge-backend-opts: Document that merge strategies can now take their own options Extend merge-subtree tests to test -Xsubtree=dir. Make "subtree" part more orthogonal to the rest of merge-recursive. pull: Fix parsing of -X

pull: Fix parsing of -X

2010-01-18T06:46:27Z

As -X parameter can contain arbitrary $IFS characters, we need to properly quote it from the shell while forming the command line. Signed-off-by: Junio C Hamano

Teach git-pull to pass -X

2010-01-18T06:45:17Z

This needs the usual sq then eval trick to allow IFS characters in the option. Signed-off-by: Avery Pennarun Signed-off-by: Junio C Hamano