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

Merge branch 'jk/pull-into-dirty-unborn' into maint

2013-07-15T17:35:43Z

"git pull" into nothing trashed "local changes" that were in the index. * jk/pull-into-dirty-unborn: pull: merge into unborn by fast-forwarding from empty tree pull: update unborn branch tip after index

pull: merge into unborn by fast-forwarding from empty tree

2013-06-20T22:51:35Z

The logic for pulling into an unborn branch was originally designed to be used on a newly-initialized repository (d09e79c, git-pull: allow pulling into an empty repository, 2006-11-16). It thus did not initially deal with uncommitted changes in the unborn branch. The case of an _unstaged_ untracked file was fixed by 4b3ffe5 (pull: do not clobber untracked files on initial pull, 2011-03-25). However, it still clobbered existing staged files, both when the file exists in the merged commit (it will be overwritten), and when it does not (it will be deleted). We fix this by doing a two-way merge, where the "current" side of the merge is an empty tree, and the "target" side is HEAD (already updated to FETCH_HEAD at this point). This amounts to claiming that all work in the index was done vs. an empty tree, and thus all content of the index is precious. Note that this use of read-tree just gives us protection against overwriting index and working tree changes. It will not actually result in a 3-way merge conflict in the index. This is fine, as this is a rare situation, and the conflict would not be interesting anyway (it must, by definition, be an add/add conflict with the whole content conflicting). And it makes it simpler for the user to recover, as they have no HEAD to "git reset" back to. Reported-by: Stefan Schüßler Signed-off-by: Thomas Rast Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

pull: update unborn branch tip after index

2013-06-20T22:51:25Z

When commit d09e79c taught git to pull into an unborn branch, it first updated the unborn branch to point at the pulled commit, and then used read-tree to update the index and working tree. That ordering made sense, since any failure of the latter step would be due to filesystem errors, and one could then recover with "git reset --hard". Later, commit 4b3ffe5 added extra safety for existing files in the working tree by asking read-tree to bail out when it would overwrite such a file. This error mode is much less "your pull failed due to random errors" and more like "we reject this pull because it would lose data". In that case, it makes sense not to update the HEAD ref, just as a regular rejected merge would do. This patch reverses the order of the update-ref and read-tree calls, so that we do not touch the HEAD ref at all if a merge is rejected. This also means that we would not update HEAD in case of a transient filesystem error, but those are presumably less rare (and one can still recover by repeating the pull, or by accessing FETCH_HEAD directly). While we're reorganizing the code, we can drop the "exit 1" from the end of our command chain. We exit immediately either way, and just calling exit without an argument will use the exit code from the last command. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

merge/pull: verify GPG signatures of commits being merged

2013-04-01T02:23:59Z

When --verify-signatures is specified on the command-line of git-merge or git-pull, check whether the commits being merged have good gpg signatures and abort the merge in case they do not. This allows e.g. auto-deployment from untrusted repo hosts. Signed-off-by: Sebastian Götte Signed-off-by: Junio C Hamano

pull: Apply -q and -v options to rebase mode as well

2013-03-17T06:30:08Z

git pull passed -q and -v only to git merge, but they can be useful for git rebase as well, so pass them there, too. In particular, using -q shuts up the "Already up-to-date." message. Especially, a new test script runs the same "pull --rebase" twice to make sure both cases are quiet, when it has something to fetch and when it is already up to date. Signed-off-by: Peter Eisentraut Signed-off-by: Junio C Hamano

git-pull: Avoid merge-base on detached head

2012-10-25T09:32:11Z

git pull --rebase does some clever tricks to find the base for $upstream, but it forgets that we may not have any branch at all. When this happens, git merge-base reports its "usage" help in the middle of an otherwise successful rebase operation, because git-merge is called with one too few parameters. Since we do not need the merge-base trick in the case of a detached HEAD, detect this condition and bypass the clever trick and the usage noise. Signed-off-by: Phil Hord Signed-off-by: Jeff King

Make git-{pull,rebase} message without tracking information friendlier

2012-03-05T07:00:57Z

The current message is too long and at too low a level for anybody to understand it if they don't know about the configuration format already. The text about setting up a remote is superfluous and doesn't help understand or recover from the error that has happened. Show the usage more prominently and explain how to set up the tracking information. If there is only one remote, that name is used instead of the generic . Also simplify the message we print on detached HEAD to remove unnecessary information which is better left for the documentation. Signed-off-by: Carlos Martín Nieto Signed-off-by: Junio C Hamano

"git pull" doesn't know "--edit"

2012-02-13T03:24:47Z

Ok, so now "git merge" defaults to editing when interactive - lovely. But when testing that, I noticed that while you can say git merge --[no-]edit ..branch.. that does not work with "git pull". You get a message like error: unknown option `no-edit' usage: git fetch [] [ [...]] or: git fetch [] or: git fetch --multiple [] [( | )...] or: git fetch --all [] -v, --verbose be more verbose -q, --quiet be more quiet --all fetch from all remotes ... which is because that stupid shell script doesn't know about the new flags, and just passes it to "git fetch" instead. Now, I really wanted to just make "git pull" a built-in instead of that nasty shell script, but I'm lazy. So here's the trivial updates to git-pull.sh to at least teach it about -e/--edit/--no-edit. Signed-off-by: Linus Torvalds Signed-off-by: Junio C Hamano

Merge branch 'ab/pull-rebase-config'

2011-12-09T21:37:01Z

* ab/pull-rebase-config: pull: introduce a pull.rebase option to enable --rebase

pull: introduce a pull.rebase option to enable --rebase

2011-11-07T16:43:11Z

Currently we either need to set branch..rebase for existing branches if we'd like "git pull" to mean "git pull --rebase", or have the forethought of setting "branch.autosetuprebase" before we create the branch. Introduce a "pull.rebase" option to globally configure "git pull" to mean "git pull --rebase" for any branch. This option will be considered at a lower priority than branch..rebase, i.e. we could set pull.rebase=true and branch..rebase=false and the latter configuration option would win. Reviewed-by: Sverre Rabbelier Reviewed-by: Fernando Vezzosi Reviewed-by: Eric Herman Signed-off-by: Ævar Arnfjörð Bjarmason Liked-by: Johannes Schindelin Signed-off-by: Junio C Hamano