{"thread":{"id":"31297","subject":"How to request a fast-forward pull","startedAt":"2012-08-20T20:40:33Z","lastAt":"2012-08-23T00:31:07Z","messageCount":4,"participants":["Jonathan Nieder","Jeff King","Junio C Hamano","Ben Hutchings"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"197437","messageId":"20120820204033.GA636@mannheim-rule.local","threadId":"31297","inReplyTo":"20120820202803.GA8378@windriver.com","subject":"How to request a fast-forward pull","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2012-08-20T20:40:33Z","receivedAt":"2012-08-20T20:40:33Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi gitsters,\n\nPaul Gortmaker wrote:\n\n> When you have a moment, would you please migrate this\n> across to your main linux-stable repository?\n>\n> Both a branch and signed tag are present and pointing at\n> the same commit, but \"git request-pull\" does favour output\n> of the tag over the branch name.\n>\n> But merging the tag will want to create a merge commit.\n>\n> So, to avoid a merge commit in your repo, you can fetch\n> (fast fwd) into your (local) branch from my branch at:\n>\n>  git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-stable.git linux-2.6.34.y\n>\n> and then fetch the signed tag listed below after that.\n\nCan this be made easier?  I could imagine request-pull learning\n--ff-only that generates a message like\n\n\tGreg,\n\n\tPlease pull --ff-only\n\n\t git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-stable.git linux-2.6.34.y\n\n\tto get the following changes [...]\n\nwhich could work ok if the recipient notices the --ff-only, but I\nwonder if there is a simpler way.\n\nThanks for the food for thought,\nJonathan\n"},{"id":"197508","messageId":"20120821064138.GA3238@sigill.intra.peff.net","threadId":"31297","inReplyTo":"20120820204033.GA636@mannheim-rule.local","subject":"Re: How to request a fast-forward pull","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-08-21T06:41:38Z","receivedAt":"2012-08-21T06:41:38Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 20, 2012 at 01:40:33PM -0700, Jonathan Nieder wrote:\n\n> > When you have a moment, would you please migrate this\n> > across to your main linux-stable repository?\n> >\n> > Both a branch and signed tag are present and pointing at\n> > the same commit, but \"git request-pull\" does favour output\n> > of the tag over the branch name.\n> >\n> > But merging the tag will want to create a merge commit.\n> >\n> > So, to avoid a merge commit in your repo, you can fetch\n> > (fast fwd) into your (local) branch from my branch at:\n> >\n> >  git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-stable.git linux-2.6.34.y\n> >\n> > and then fetch the signed tag listed below after that.\n> \n> Can this be made easier?  I could imagine request-pull learning\n> --ff-only that generates a message like\n> \n> \tGreg,\n> \n> \tPlease pull --ff-only\n> \n> \t git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-stable.git linux-2.6.34.y\n> \n> \tto get the following changes [...]\n> \n> which could work ok if the recipient notices the --ff-only, but I\n> wonder if there is a simpler way.\n\nIf it is something important for the sender to communicate to the\nrecipient as part of the pull command-line, then I would think the\nnatural place is on the line with the rest of it, like:\n\n  Please pull:\n\n    --ff-only <remote> <ref>\n\nIt's maximally noticeable to the recipient, then, and anybody\ncutting-and-pasting the whole line would get it automagically. That is\nas close to machine-readable as pull-request emails get.\n\nHowever, I have to wonder if that is a good idea in general. Isn't the\ndecision to --ff-only or not really the puller's business? In the\ngeneral case, I would not expect senders of pull request to have advice\nin this area.\n\nThis particular case seems to be caused by a policy mismatch between the\nproject and request-pull. The latter's behavior to favor a matching tag\nis because tags carry more information. But in this case, it sounds like\nthe project would rather avoid the extra merge commits, even if it means\nlosing information. So the right solution would be to teach request-pull\nan option to follow the project's policy better.\n\nOr is this just a one-off thing? In that case, the simplest thing would\nbe to tweak the pull-request email to mention the branch name instead of\nthe tag, rather than talking about --ff-only.\n\n-Peff\n"},{"id":"197538","messageId":"7vwr0sdute.fsf@alter.siamese.dyndns.org","threadId":"31297","inReplyTo":"20120821064138.GA3238@sigill.intra.peff.net","subject":"Re: How to request a fast-forward pull","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-08-21T17:22:05Z","receivedAt":"2012-08-21T17:22:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Mon, Aug 20, 2012 at 01:40:33PM -0700, Jonathan Nieder wrote:\n>\n>> > When you have a moment, would you please migrate this\n>> > across to your main linux-stable repository?\n>> >\n>> > Both a branch and signed tag are present and pointing at\n>> > the same commit, but \"git request-pull\" does favour output\n>> > of the tag over the branch name.\n>> >\n>> > But merging the tag will want to create a merge commit.\n>> >\n>> > So, to avoid a merge commit in your repo, you can fetch\n>> > (fast fwd) into your (local) branch from my branch at:\n>> >\n>> >  git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-stable.git linux-2.6.34.y\n>> >\n>> > and then fetch the signed tag listed below after that.\n>> \n>> Can this be made easier?  I could imagine request-pull learning\n>> --ff-only that generates a message like\n>> \n>> \tGreg,\n>> \n>> \tPlease pull --ff-only\n\nWhere did the \"Greg,\\n\\n\" come from?  Isn't it just the matter of\nadding the \"--ff-only\" when that string is added?\n\n>> \n>> \t git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-stable.git linux-2.6.34.y\n>> \n>> \tto get the following changes [...]\n>> \n>> which could work ok if the recipient notices the --ff-only, but I\n>> wonder if there is a simpler way.\n>\n> If it is something important for the sender to communicate to the\n> recipient as part of the pull command-line, then I would think the\n> natural place is on the line with the rest of it, like:\n>\n>   Please pull:\n>\n>     --ff-only <remote> <ref>\n>\n> It's maximally noticeable to the recipient, then, and anybody\n> cutting-and-pasting the whole line would get it automagically. That is\n> as close to machine-readable as pull-request emails get.\n>\n> However, I have to wonder if that is a good idea in general. Isn't the\n> decision to --ff-only or not really the puller's business? In the\n> general case, I would not expect senders of pull request to have advice\n> in this area.\n\nYes, absolutely.  The advice of the sender that would be more\nhelpful is not \"how\", but \"where\"/\"when\".  Is the topic meant for\nthe maintenance track?  Why is it appropriate to pull this series at\nthis moment in the history of the overall project?\n\n> This particular case seems to be caused by a policy mismatch between the\n> project and request-pull. The latter's behavior to favor a matching tag\n> is because tags carry more information. But in this case, it sounds like\n> the project would rather avoid the extra merge commits, even if it means\n> losing information.\n\nThat's a project decision and can be done by whoever is pulling, as\nyou mentioned earlier.\n\nIn any case, why is this even become an issue in the context of\nlinux-stable?  I thought people over there were working hard to\n*increase* verifiability of the history by using signed merges,\nwhile strongly discouraging to rebase history (which is wholly\nincompatible with insisting on fast-forwardness).  I _think_ the\noriginal submitter meant to say \"the whole of my work is based on\nyour latest, so you _could_ fast forward\", and did not even mean \"I\ndo not want to see any merge commit (or I understand you do not want\nto see one), and here is an instruction to work my pull request\naround\".  If the latter were the case (which I doubt is the case\nhere, as it is a stupid thing to say in the context of Linux kernel\nproject), your \"mention the branch name instead\" would make sense.\n"},{"id":"197671","messageId":"1345681867.15245.36.camel@deadeye.wl.decadent.org.uk","threadId":"31297","inReplyTo":"7vwr0sdute.fsf@alter.siamese.dyndns.org","subject":"Re: How to request a fast-forward pull","fromName":"Ben Hutchings","fromEmail":"ben@decadent.org.uk","sentAt":"2012-08-23T00:31:07Z","receivedAt":"2012-08-23T00:31:07Z","isPatch":false,"sender":{"key":"ben@decadent.org.uk","avatar":null},"body":"On Tue, 2012-08-21 at 10:22 -0700, Junio C Hamano wrote:\n> Jeff King <peff@peff.net> writes:\n> \n> > On Mon, Aug 20, 2012 at 01:40:33PM -0700, Jonathan Nieder wrote:\n> >\n> >> > When you have a moment, would you please migrate this\n> >> > across to your main linux-stable repository?\n> >> >\n> >> > Both a branch and signed tag are present and pointing at\n> >> > the same commit, but \"git request-pull\" does favour output\n> >> > of the tag over the branch name.\n> >> >\n> >> > But merging the tag will want to create a merge commit.\n> >> >\n> >> > So, to avoid a merge commit in your repo, you can fetch\n> >> > (fast fwd) into your (local) branch from my branch at:\n> >> >\n> >> >  git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-stable.git linux-2.6.34.y\n> >> >\n> >> > and then fetch the signed tag listed below after that.\n> >> \n> >> Can this be made easier?  I could imagine request-pull learning\n> >> --ff-only that generates a message like\n> >> \n> >> \tGreg,\n> >> \n> >> \tPlease pull --ff-only\n> \n> Where did the \"Greg,\\n\\n\" come from?  Isn't it just the matter of\n> adding the \"--ff-only\" when that string is added?\n> \n> >> \n> >> \t git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-stable.git linux-2.6.34.y\n> >> \n> >> \tto get the following changes [...]\n> >> \n> >> which could work ok if the recipient notices the --ff-only, but I\n> >> wonder if there is a simpler way.\n> >\n> > If it is something important for the sender to communicate to the\n> > recipient as part of the pull command-line, then I would think the\n> > natural place is on the line with the rest of it, like:\n> >\n> >   Please pull:\n> >\n> >     --ff-only <remote> <ref>\n> >\n> > It's maximally noticeable to the recipient, then, and anybody\n> > cutting-and-pasting the whole line would get it automagically. That is\n> > as close to machine-readable as pull-request emails get.\n> >\n> > However, I have to wonder if that is a good idea in general. Isn't the\n> > decision to --ff-only or not really the puller's business? In the\n> > general case, I would not expect senders of pull request to have advice\n> > in this area.\n> \n> Yes, absolutely.  The advice of the sender that would be more\n> helpful is not \"how\", but \"where\"/\"when\".  Is the topic meant for\n> the maintenance track?  Why is it appropriate to pull this series at\n> this moment in the history of the overall project?\n> \n> > This particular case seems to be caused by a policy mismatch between the\n> > project and request-pull. The latter's behavior to favor a matching tag\n> > is because tags carry more information. But in this case, it sounds like\n> > the project would rather avoid the extra merge commits, even if it means\n> > losing information.\n> \n> That's a project decision and can be done by whoever is pulling, as\n> you mentioned earlier.\n> \n> In any case, why is this even become an issue in the context of\n> linux-stable?  I thought people over there were working hard to\n> *increase* verifiability of the history by using signed merges,\n[...]\n\nEach *stable update* series is a single branch made up almost entirely\nof cherry-picked commits, possibly managed as a quilt series before\nbeing reviewed and then committed.  Tags are signed, and each commit has\na reference to the original (though the format of that reference isn't\nwell standardised).\n\nAlthough Greg owns the linux-stable.git repository, several stable\nupdates series and the corresponding branches are maintained by others,\nsuch as Paul and myself.  When Greg pulls from them, he's mirroring the\nother maintainer's branch and never merging with anyone else's work.  So\nit should always be a fast-forward merge.  Further, the head of the\nbranch is always going to have a tag signed by the respective\nmaintainer.\n\nBen.\n\n-- \nBen Hutchings\nExperience is what causes a person to make new mistakes instead of old ones.\n"}]}