Jeff King <> writes:

> On Mon, Aug 20, 2012 at 01:40:33PM -0700, Jonathan Nieder wrote:
>> > When you have a moment, would you please migrate this
>> > across to your main linux-stable repository?
>> >
>> > Both a branch and signed tag are present and pointing at
>> > the same commit, but "git request-pull" does favour output
>> > of the tag over the branch name.
>> >
>> > But merging the tag will want to create a merge commit.
>> >
>> > So, to avoid a merge commit in your repo, you can fetch
>> > (fast fwd) into your (local) branch from my branch at:
>> >
>> >  git:// 
>> > linux-2.6.34.y
>> >
>> > and then fetch the signed tag listed below after that.
>> Can this be made easier?  I could imagine request-pull learning
>> --ff-only that generates a message like
>>      Greg,
>>      Please pull --ff-only

Where did the "Greg,\n\n" come from?  Isn't it just the matter of
adding the "--ff-only" when that string is added?

>>       git:// 
>> linux-2.6.34.y
>>      to get the following changes [...]
>> which could work ok if the recipient notices the --ff-only, but I
>> wonder if there is a simpler way.
> If it is something important for the sender to communicate to the
> recipient as part of the pull command-line, then I would think the
> natural place is on the line with the rest of it, like:
>   Please pull:
>     --ff-only <remote> <ref>
> It's maximally noticeable to the recipient, then, and anybody
> cutting-and-pasting the whole line would get it automagically. That is
> as close to machine-readable as pull-request emails get.
> However, I have to wonder if that is a good idea in general. Isn't the
> decision to --ff-only or not really the puller's business? In the
> general case, I would not expect senders of pull request to have advice
> in this area.

Yes, absolutely.  The advice of the sender that would be more
helpful is not "how", but "where"/"when".  Is the topic meant for
the maintenance track?  Why is it appropriate to pull this series at
this moment in the history of the overall project?

> This particular case seems to be caused by a policy mismatch between the
> project and request-pull. The latter's behavior to favor a matching tag
> is because tags carry more information. But in this case, it sounds like
> the project would rather avoid the extra merge commits, even if it means
> losing information.

That's a project decision and can be done by whoever is pulling, as
you mentioned earlier.

In any case, why is this even become an issue in the context of
linux-stable?  I thought people over there were working hard to
*increase* verifiability of the history by using signed merges,
while strongly discouraging to rebase history (which is wholly
incompatible with insisting on fast-forwardness).  I _think_ the
original submitter meant to say "the whole of my work is based on
your latest, so you _could_ fast forward", and did not even mean "I
do not want to see any merge commit (or I understand you do not want
to see one), and here is an instruction to work my pull request
around".  If the latter were the case (which I doubt is the case
here, as it is a stupid thing to say in the context of Linux kernel
project), your "mention the branch name instead" would make sense.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to