Uwe Kleine-König <u.kleine-koe...@pengutronix.de> writes:
> Hello Linus,
>
> On Wed, Jun 25, 2014 at 05:05:51AM -0700, Linus Torvalds wrote:
>> On Wed, Jun 25, 2014 at 2:55 AM, Uwe Kleine-König
>> <u.kleine-koe...@pengutronix.de> wrote:
>> >
>> > $ git rev-parse HEAD
>> > 9e065e4a5a58308f1a0da4bb80b830929dfa90b3
>> > $ git ls-remote origin | grep
>> > 9e065e4a5a58308f1a0da4bb80b830929dfa90b3
>> > 9e065e4a5a58308f1a0da4bb80b830929dfa90b3
>> > refs/heads/ukl/for-mainline
>> > $ git request-pull origin/master origin HEAD > /dev/null
>> > warn: No match for commit 9e065e4a5a58308f1a0da4bb80b830929dfa90b3
>> > found at origin
>> > warn: Are you sure you pushed 'HEAD' there?
>>
>> Notice how "HEAD" does not match.
>>
>> The error message is perhaps misleading. It's not enough to match the
>> commit. You need to match the branch name too. git used to guess the
>> branch name (from the commit), and it often guessed wrongly. So now
>> they need to match.
>>
>> So you should do
>>
>> git request-pull origin/master origin ukl/for-mainline
>>
>> to let request-pull know that you're requesting a pull for
>> "ukl/for-mainline".
Or
git request-pull origin/master origin HEAD:ukl/for-mainline
I am not Linus, and do not speak for him, but FWIW here are some
comments on the ideas.
> I liked git guessing the branch name, maybe we can teach it to guess a
> bit better than it did before 2.0? Something like:
>
> - if there is a unique match on the remote side, use it.
I am on the fence but slightly leaning to the negative side on this
one. The branch/ref the object was took from when "git pull" is run
does matter, because the name is recorded in the merge summary, so
we cannot say "There are refs that happen to point at the object you
wanted to be pulled, so we'll pick one of them let the integrator
pull from that ref we randomly chose" is not something we would
want. "If there is a unique one, that must be the one the user has
meant; there is nothing else possible" feels like a strong argument,
and I was actually contemplating about doing an enhancement on top
of Linus's original myself along that line, back when we queued that
patch exactly for that reason.
But a counter-argument, in the context of Linus's change in question
being primarily to avoid end-user mistakes resulting in a bogus
request, is that the ref on the remote that happens to match the
object but is different from what the user named may be a totally
unrelated branch before the user actually has pushed the set of
changes the request is going to ask to be pulled. The mistake that
this extra strictness tries to avoid is to compose request-pull
before pushing what to be pulled and then forgetting to push.
> - if there are >= 1 match on the remote side and exactly one matches
> what I specified as <end>, use it.
The original change by Linus being about avoiding mistakes by
requiring the user to name what to be pulled, i.e. <end>, this point
of "other refs also happen to point at the same object" is made
irrelevant---if <end> does have the object the user named to be
pulled, that should be used regardless of where other refs point at.
> - if there are >= 1 match on the remote side and exactly one of them is
> a tag, use the tag
>
> - if there are two matches on the remote side, and one is "HEAD",
> pick the other one.
Assuming that <end> does not match the object in these two cases
(otherwise your second condition would have caught it), they share
the same potential objection as the first one.
I dunno.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
