Re: How to request a fast-forward pull
Jeff King <peff@peff.net> writes:
Show 24 quoted lines
> 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://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-stable.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?
Show 24 quoted lines
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-stable.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?
Show 5 quoted lines
> 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.
Jonathan Nieder
