Jeff King <p...@peff.net> 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://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
>> 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?
>> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html