pull: update unborn branch tip after index
commit9f48f2bd9ae8db8cdce3a8e2c9b6dc33b2a55ee1
authorJeff King <peff@peff.net>
Thu, 20 Jun 2013 22:36:31 +0000 (20 18:36 -0400)
committerJunio C Hamano <gitster@pobox.com>
Thu, 20 Jun 2013 22:51:25 +0000 (20 15:51 -0700)
tree7ea8188b2f7e636c241cb560cd946bc261e039ca
parentb3b8ceb48b7d75631a8638f1dc6ccdf7f1b53888
pull: update unborn branch tip after index

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 <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-pull.sh