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