request-pull: more strictly match local/remote branches
commit024d34cb0813e098c5c0e4ccdacb6a461d34cb6b
authorLinus Torvalds <torvalds@linux-foundation.org>
Wed, 22 Jan 2014 20:32:30 +0000 (22 12:32 -0800)
committerJunio C Hamano <gitster@pobox.com>
Tue, 25 Feb 2014 20:52:28 +0000 (25 12:52 -0800)
tree8e2918e7243cd2d1cc7198fdc2f6c590222026d2
parentb594c975c7e865be23477989d7f36157ad437dc7
request-pull: more strictly match local/remote branches

The current 'request-pull' will try to find matching commit on the given
remote, and rewrite the "please pull" line to match that remote ref.

That may be very helpful if your local tree doesn't match the layout of
the remote branches, but for the common case it's been a recurring
disaster, when "request-pull" is done against a delayed remote update, and
it rewrites the target branch randomly to some other branch name that
happens to have the same expected SHA1 (or more commonly, leaves it
blank).

To avoid that recurring problem, this changes "git request-pull" so that
it matches the ref name to be pulled against the *local* repository, and
then warns if the remote repository does not have that exact same branch
or tag name and content.

This means that git request-pull will never rewrite the ref-name you gave
it.  If the local branch name is "xyzzy", that is the only branch name
that request-pull will ask the other side to fetch.

If the remote has that branch under a different name, that's your problem
and git request-pull will not try to fix it up (but git request-pull will
warn about the fact that no exact matching branch is found, and you can
edit the end result to then have the remote name you want if it doesn't
match your local one).

The new "find local ref" code will also complain loudly if you give an
ambiguous refname (eg you have both a tag and a branch with that same
name, and you don't specify "heads/name" or "tags/name").

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-request-pull.sh