* fc/trivial:
  pull: use $curr_branch_short more
  add: trivial style cleanup
  reset: trivial style cleanup
  branch: trivial style fix
  reset: trivial refactoring

One of the first things git-pull.sh does is setting $curr_branch to
the target of HEAD and $curr_branch_short to the same but with the
leading "refs/heads/" removed.  Simplify the code by using
$curr_branch_short instead of setting $curr_branch to the same
shortened value.

The only other use of $curr_branch in that function doesn't have to
be replaced with $curr_branch_short because it just checks if the
string is empty.  That property is the same with or without the prefix
unless HEAD points to "refs/heads/" alone, which is invalid.

Noticed-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

If a user is working on master, and has merged in their feature branch, but now
has to "git pull" because master moved, with pull.rebase their feature branch
will be flattened into master.

This is because "git pull" currently does not know about rebase's preserve
merges flag, which would avoid this behavior, as it would instead replay just
the merge commit of the feature branch onto the new master, and not replay each
individual commit in the feature branch.

Add a --rebase=preserve option, which will pass along --preserve-merges to
rebase.

Also add 'preserve' to the allowed values for the pull.rebase config setting.

Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

* jk/pull-to-integrate:
  pull: change the description to "integrate" changes
  push: avoid suggesting "merging" remote changes

Since git-pull learned the --rebase option it has not just been about
merging changes from a remote repository (where "merge" is in the sense
of "git merge").  Change the description to use "integrate" instead of
"merge" in order to reflect this.

Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

"git pull" into nothing trashed "local changes" that were in the
index, and this avoids it.

* jk/pull-into-dirty-unborn:
  pull: merge into unborn by fast-forwarding from empty tree
  pull: update unborn branch tip after index

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 <mail@stefanschuessler.de>
Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

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>

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 <jaseg@physik-pool.tu-berlin.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

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 <peter@eisentraut.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>