From: Linus Torvalds torva...@linux-foundation.org
Date: Wed, 22 Jan 2014 12:32:30 -0800
Subject: [PATCH] Make 'git request-pull' more strict about matching
local/remote branches
The current 'request-pull' will try to find matching commit on the given
remote, and rewrite the please pull line
Linus Torvalds torva...@linux-foundation.org writes:
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
On Wed, Jan 22, 2014 at 1:46 PM, Junio C Hamano gits...@pobox.com wrote:
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).
But this part might be a
On Wed, Jan 22, 2014 at 2:03 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
Any ideas? The hacky way is to do | head -1 to take the first
show-ref output, and then check if you get a different result if you
re-do it using show-ref --tags. But that sounds really excessively
hacky. Is
Linus Torvalds torva...@linux-foundation.org writes:
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
On Wed, Jan 22, 2014 at 2:14 PM, Junio C Hamano gits...@pobox.com wrote:
I looked at 5150.4 and found that what it attempts to do is halfway
sensible.
I agree that it is half-way sensible. The important bit being the HALF part.
The half part is why we have the semantics we have. There's no
Junio C Hamano gits...@pobox.com writes:
... there is no 'for-linus' branch locally, so there is no way for
him to say
git request-pull initial origin for-linus
unless he creates it locally first.
In real life on the kernel list, for-linus may have to be a signed
tag, and pushed
7 matches
Mail list logo
