{"thread":{"id":"33162","subject":"Re: linux-next: unneeded merge in the security tree","startedAt":"2013-03-12T17:13:21Z","lastAt":"2013-03-13T03:17:27Z","messageCount":12,"participants":["Linus Torvalds","Geert Uytterhoeven","Junio C Hamano","Theodore Ts'o"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"211143","messageId":"CA+55aFzFLDcN-1GKae6Xqrns59K1xOD_HPzuv2Lv1__fZpqFMw@mail.gmail.com","threadId":"33162","inReplyTo":"20130312041641.GE18595@thunk.org","subject":"Re: linux-next: unneeded merge in the security tree","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2013-03-12T17:13:21Z","receivedAt":"2013-03-12T17:13:21Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"[ Added Junio and git to the recipients, and leaving a lot of stuff\nquoted due to that... ]\n\nOn Mon, Mar 11, 2013 at 9:16 PM, Theodore Ts'o wrote:\n> On Tue, Mar 12, 2013 at 03:10:53PM +1100, James Morris wrote:\n>> On Tue, 12 Mar 2013, Stephen Rothwell wrote:\n>> > The top commit in the security tree today is a merge of v3.9-rc2. This\n>> > is a completely unnecessary merge as the tree before the merge was a\n>> > subset of v3.9-rc1 and so if the merge had been done using anything but\n>> > the tag, it would have just been a fast forward. I know that this is now\n>> > deliberate behaviour on git's behalf, but isn't there some way we can\n>> > make this easier on maintainers who are just really just trying to pick a\n>> > new starting point for their trees after a release? (at least I assume\n>> > that is what James was trying to do)\n>>\n>> Yes, and I was merging to a tag as required by Linus.\n\nNow, quite frankly, I'd prefer people not merge -rc tags either, just\nreal releases. -rc tags are certainly *much* better than merging\nrandom daily stuff, but the basic rule should be \"don't back-merge AT\nALL\" rather than \"back-merge tags\".\n\nThat said, you didn't really want a merge at all, you just wanted to\nsync up and start development. Which is different (but should still\nprefer real releases, and only use rc tags if it's fixing stuff that\nhappened in the merge window - which may be the case here).\n\n> Why not just force the head of the security tree to be v3.9-rc2? Then\n> you don't end up creating a completely unnecessary merge commit, and\n> users who were at the previous head of the security tree will\n> experience a fast forward when they pull your new head.\n\nSo I think that may *technically* be the right solution, but it's a\nrather annoying UI issue, partly because you can't just do it in a\nsingle operation (you can't do a pull of the tag to both fetch and\nfast-forward it), but partly because \"git reset --hard\" is also an\noperation that can lose history, so it's something that people should\nbe nervous about, and shouldn't use as some kind of standard \"let's\njust fast-forward to Linus' tree\" thing.\n\nAt the same time, it's absolutely true that when *I* pull a signed tag\nfrom a downstream developer, I don't want a fast-forward, because then\nI'd lose the signature. So when a maintainer pulls a submaintainer\ntree, you want the signature to come upstream, but when a\nsubmaintainer wants to just sync up with upstream, you don't want to\ngenerate the pointless signed merge commit, because the signature is\nalready upstream because it's a public tag. So gthe behavior of \"git\npull\" is fundamentally ambiguous.\n\nBut git doesn't know the difference between \"official public upstream\ntag\" and \"signed tag used to verify the pull request\".\n\nI'm adding the git list just to get this issue out there and see if\npeople have any ideas. I've got a couple of workarounds, but they\naren't wonderful..\n\nOne is simple:\n\n git config alias.sync=\"pull --ff-only\"\n\nwhich works fine, but forces submaintainers to be careful when doing\nthings like this, and using a special command to do back-merges.\n\nAnd maybe that's the right thing to do? Back-merges *are* special,\nafter all. But the above alias is particularly fragile, in that\nthere's both \"pull\" and \"merge\" that people want to use this for, and\nit doesn't really handle both. And --ff-only will obviously fail if\nyou actually have some work in your tree, and want to do a real merge,\nso then you have to do that differently. So I'm mentioning this as a\nbetter model than \"git reset\", but not really a *solution*.\n\nThat said, the fact that \"--ff-only\" errors out if you have local\ndevelopment may actually be a big bonus - because you really shouldn't\ndo merges at all if you have local development, but syncing up to my\ntree if you don't have it (and are going to start it) may be something\nreasonable.\n\nNow, the other approach - and perhaps preferable, but requiring actual\nchanges to git itself - is to do the non-fast-forward merge *only* for\nFETCH_HEAD, which already has magic semantics in other ways. So if\nsomebody does\n\n git fetch linus\n git merge v3.8\n\nto sync with me, they would *not* get a merge commit with a signature,\njust a fast-forward. But if you do\n\n git pull linus v3.8\n\nor a\n\n git fetch linus v3.8\n git merge FETCH_HEAD\n\nit would look like a \"maintainer merge\" and stash the signature in the\nmerge commit rather than fast-forward. It would probably work in\npractice.\n\nThe final approach might be to make it like the \"merge summary\" and\nsimply make it configurable _and_ have a command line flag for it,\ndefaulting to our current behavior or to the above suggested \"default\non for FETCH_HEAD, off for anything else\".\n\nHmm?\n\n Linus\n"},{"id":"211145","messageId":"CAMuHMdXaf_wfmwpQ4O5v+n8vd4uwddDANyZna4ufK10JxZhSvA@mail.gmail.com","threadId":"33162","inReplyTo":"CA+55aFzFLDcN-1GKae6Xqrns59K1xOD_HPzuv2Lv1__fZpqFMw@mail.gmail.com","subject":"Re: linux-next: unneeded merge in the security tree","fromName":"Geert Uytterhoeven","fromEmail":"geert@linux-m68k.org","sentAt":"2013-03-12T17:51:44Z","receivedAt":"2013-03-12T17:51:44Z","isPatch":false,"sender":{"key":"geert@linux-m68k.org","avatar":"https://gravatar.com/avatar/8105b34f653a7b5b98e225e565b11ebcc762ad4ab1a9d905a4663db029a9e6bc?d=mp&s=160"},"body":"On Tue, Mar 12, 2013 at 6:13 PM, Linus Torvalds\n wrote:\n>> Why not just force the head of the security tree to be v3.9-rc2? Then\n>> you don't end up creating a completely unnecessary merge commit, and\n>> users who were at the previous head of the security tree will\n>> experience a fast forward when they pull your new head.\n>\n> So I think that may *technically* be the right solution, but it's a\n> rather annoying UI issue, partly because you can't just do it in a\n> single operation (you can't do a pull of the tag to both fetch and\n> fast-forward it), but partly because \"git reset --hard\" is also an\n> operation that can lose history, so it's something that people should\n> be nervous about, and shouldn't use as some kind of standard \"let's\n> just fast-forward to Linus' tree\" thing.\n\nIn many cases, \"git rebase x\" does the exact same thing as\n\"git reset --hard x\", with an added safeguard: if you forgot to upstream\nsomething, it'll boil up on top of \"x\".\n\nGr{oetje,eeting}s,\n\n Geert\n\n--\nGeert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org\n\nIn personal conversations with technical people, I call myself a hacker. But\nwhen I'm talking to journalists I just say \"programmer\" or something like that.\n -- Linus Torvalds\n"},{"id":"211156","messageId":"7vsj40760d.fsf@alter.siamese.dyndns.org","threadId":"33162","inReplyTo":"CA+55aFzFLDcN-1GKae6Xqrns59K1xOD_HPzuv2Lv1__fZpqFMw@mail.gmail.com","subject":"Re: linux-next: unneeded merge in the security tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-12T19:49:38Z","receivedAt":"2013-03-12T19:49:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> One is simple:\n>\n> git config alias.sync=\"pull --ff-only\"\n\nHeh, I just wrote that myself after reading the early part of this\nmessage ;-)\n\n> which works fine, but forces submaintainers to be careful when doing\n> things like this, and using a special command to do back-merges.\n\n> And maybe that's the right thing to do? Back-merges *are* special,\n\nYes.\n\n> after all. But the above alias is particularly fragile, in that\n> there's both \"pull\" and \"merge\" that people want to use this for, and\n> it doesn't really handle both. And --ff-only will obviously fail if\n> you actually have some work in your tree, and want to do a real merge,\n> so then you have to do that differently. So I'm mentioning this as a\n> better model than \"git reset\", but not really a *solution*.\n\n> That said, the fact that \"--ff-only\" errors out if you have local\n> development may actually be a big bonus - because you really shouldn't\n> do merges at all if you have local development, but syncing up to my\n> tree if you don't have it (and are going to start it) may be something\n> reasonable.\n\nYes, that's the reasoning behind all the behaviours you described\nabove.\n\n> Now, the other approach - and perhaps preferable, but requiring actual\n> changes to git itself - is to do the non-fast-forward merge *only* for\n> FETCH_HEAD, which already has magic semantics in other ways. So if\n> somebody does\n>\n> git fetch linus\n> git merge v3.8\n>\n> to sync with me, they would *not* get a merge commit with a signature,\n> just a fast-forward. But if you do\n>\n> git pull linus v3.8\n>\n> or a\n>\n> git fetch linus v3.8\n> git merge FETCH_HEAD\n>\n> it would look like a \"maintainer merge\"....\n\nI am not sure I follow. Are you solving the real problem, the\npointeless merge in the \"security tree\" that started this thread?\n\nI would imagine it was made by somebody thinking that pulling a\ntagged stable point from you is a good idea, like this:\n\n\tgit pull linus v3.9-rc2\n\nwhich under your FETCH_HEAD rule would look like a maintainer merge,\nno?\n\nAn alternative may be to activate the magic \"mergetag\" thing only\nwhen you give \"--no-ff\" explicitly; otherwise merge would unwrap the\ntag, whether it comes from FETCH_HEAD.\n\nThe following examples all assume that your HEAD is somewhere\nbehind v3.9-rc2, perhaps done by\n\n\tgit checkout -b test v3.8^0\n\nThen under the \"--no-ff activates the magic\" rule:\n\n\tgit merge v3.9-rc2\n\nwill fast-forward, but this\n\n\tgit merge --no-ff v3.9-rc2\n\ncreates a real merge with the \"mergetag\" signature block. The one\nthat caused trouble in the \"security tree\", i.e.\n\n git pull linus v3.9-rc2\n\nor its equivalent\n\n git fetch linus v3.9-rc2\n git merge FETCH_HEAD\n\nwould still fast-forward under this rule. The maintainer needs to\ndo\n\n\tgit pull --no-ff git://git.kernel.org/... for-linus\n\nif the pull could fast-forward under this rule, though.\n\nHaving thought this up to this point, I am not sure it generally is\na good change. It feels that \"pull --ff-only\" that prevents people\nfrom creating pointless back-merges may still be a better mechanism.\n\nI dunno.\n"},{"id":"211157","messageId":"7vobeo75f8.fsf@alter.siamese.dyndns.org","threadId":"33162","inReplyTo":"7vsj40760d.fsf@alter.siamese.dyndns.org","subject":"Re: linux-next: unneeded merge in the security tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-12T20:02:19Z","receivedAt":"2013-03-12T20:02:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Then under the \"--no-ff activates the magic\" rule:\n>\n> \tgit merge v3.9-rc2\n>\n> will fast-forward, but this\n>\n> \tgit merge --no-ff v3.9-rc2\n>\n> creates a real merge with the \"mergetag\" signature block. The one\n> that caused trouble in the \"security tree\", i.e.\n>\n> git pull linus v3.9-rc2\n>\n> or its equivalent\n>\n> git fetch linus v3.9-rc2\n> git merge FETCH_HEAD\n>\n> would still fast-forward under this rule. The maintainer needs to\n> do\n>\n> \tgit pull --no-ff git://git.kernel.org/... for-linus\n>\n> if the pull could fast-forward under this rule, though.\n\nScratch the last sentence. It should have been\n\n\"whether the pull fast-forwards or not\". You'd always need to.\n"},{"id":"211162","messageId":"20130312212027.GE14792@thunk.org","threadId":"33162","inReplyTo":"CA+55aFzFLDcN-1GKae6Xqrns59K1xOD_HPzuv2Lv1__fZpqFMw@mail.gmail.com","subject":"Re: linux-next: unneeded merge in the security tree","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2013-03-12T21:20:27Z","receivedAt":"2013-03-12T21:20:27Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"What if we added the ability to do something like this:\n\n[remote \"origin\"]\n\turl = git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n\tfetch = +refs/heads/master:refs/heads/master\n\tmergeoptions = --ff-only\n\nThis would be an analog to branch..mergeoptions, but it would\napply to the source of the pull request, instead of the destination.\n\nThat way, people who do a \"git pull\" from Linus's tree would get the\nprotection of --ff-only, while pulls from submaintainer trees would\nautomatically get a merge commit, which is what we want.\n\nIt doesn't handle the case of a submaintainer pulling from a\nmaintainer in a back-merge scenario, but that should be a pretty rare\ncase, so maybe that's OK.\n\n \t \t \t \t- Ted\n"},{"id":"211164","messageId":"CA+55aFwHJtOU4Qzt3XZsER165kTc5P0ATQP2wPHvuUiVic8bnA@mail.gmail.com","threadId":"33162","inReplyTo":"20130312212027.GE14792@thunk.org","subject":"Re: linux-next: unneeded merge in the security tree","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2013-03-12T21:28:39Z","receivedAt":"2013-03-12T21:28:39Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Tue, Mar 12, 2013 at 2:20 PM, Theodore Ts'o wrote:\n> What if we added the ability to do something like this:\n>\n> [remote \"origin\"]\n> url = git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n> fetch = +refs/heads/master:refs/heads/master\n> mergeoptions = --ff-only\n\nHmm. Something like this could be interesting for other things:\n\n - use \"--rebase\" when pulling (this is common for people who maintain\na set of patches and do *not* export their git tree - I use it for\nprojects like git and subsurface where there is an upstream maintainer\nand I usually send patches by email rather than git)\n\n - \"--no-summary\". As a maintainer, you people probably do want to\nenable summaries for people they pull from, but *not* from upstream.\nSo this might even make sense to do by default when you clone a new\nrepository.\n\n - I do think that we might want a \"--no-signatures\" for the specific\ncase of merging signed tags without actually taking the signature\n(because it's a \"upstream\" repo). The \"--ff-only\" thing is *too*\nstrict. Sometimes you really do want to merge in new code, disallowing\nit entirely is tough.\n\nOf course, I'm not really sure if we want to list the flags. Maybe\nit's better to just introduce the notion of \"upstream\" directly, and\nmake that a flag, and make \"origin\" default to that when you clone.\nAnd then have git use different heurstics for pulling upstream (like\nwarning by default when doing a back-merge, perhaps?)\n\n Linus\n"},{"id":"211165","messageId":"7vtxog5msj.fsf@alter.siamese.dyndns.org","threadId":"33162","inReplyTo":"20130312212027.GE14792@thunk.org","subject":"Re: linux-next: unneeded merge in the security tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-12T21:30:04Z","receivedAt":"2013-03-12T21:30:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Theodore Ts'o writes:\n\n> What if we added the ability to do something like this:\n>\n> [remote \"origin\"]\n> \turl = git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n> \tfetch = +refs/heads/master:refs/heads/master\n> \tmergeoptions = --ff-only\n>\n> This would be an analog to branch..mergeoptions, but it would\n> apply to the source of the pull request, instead of the destination.\n>\n> That way, people who do a \"git pull\" from Linus's tree would get the\n> protection of --ff-only, while pulls from submaintainer trees would\n> automatically get a merge commit, which is what we want.\n>\n> It doesn't handle the case of a submaintainer pulling from a\n> maintainer in a back-merge scenario, but that should be a pretty rare\n> case, so maybe that's OK.\n\nIs there an escape hatch for that rare case? IOW, how does a\nsubmaintainer who configured the above to override --ff-only?\n"},{"id":"211167","messageId":"7vppz45lz9.fsf@alter.siamese.dyndns.org","threadId":"33162","inReplyTo":"CA+55aFwHJtOU4Qzt3XZsER165kTc5P0ATQP2wPHvuUiVic8bnA@mail.gmail.com","subject":"Re: linux-next: unneeded merge in the security tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-12T21:47:38Z","receivedAt":"2013-03-12T21:47:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> - I do think that we might want a \"--no-signatures\" for the specific\n> case of merging signed tags without actually taking the signature\n> (because it's a \"upstream\" repo). The \"--ff-only\" thing is *too*\n> strict. Sometimes you really do want to merge in new code, disallowing\n> it entirely is tough.\n\nI agree that \"--ff-only\" thing is too strict and sometimes you would\nwant to allow back-merges, but when you do allow such a back-merge,\nis there a reason you want it to be --no-signatures merge? When a\nsubtree maintainer decides to merge a stable release point from you\nwith a good reason, I do not see anything wrong in recording that\nthe resulting commit _did_ merge what you released with a signature.\n"},{"id":"211168","messageId":"CA+55aFzWjfFjcRZXBO+edO7f66REA0pOsC3iZ2vYdHrkcovnHA@mail.gmail.com","threadId":"33162","inReplyTo":"7vppz45lz9.fsf@alter.siamese.dyndns.org","subject":"Re: linux-next: unneeded merge in the security tree","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2013-03-12T21:54:04Z","receivedAt":"2013-03-12T21:54:04Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Tue, Mar 12, 2013 at 2:47 PM, Junio C Hamano wrote:\n>\n> I agree that \"--ff-only\" thing is too strict and sometimes you would\n> want to allow back-merges, but when you do allow such a back-merge,\n> is there a reason you want it to be --no-signatures merge? When a\n> subtree maintainer decides to merge a stable release point from you\n> with a good reason, I do not see anything wrong in recording that\n> the resulting commit _did_ merge what you released with a signature.\n\nNo, there's nothing really bad with adding the signature to the merge\ncommit if you do make a merge. It's the fact that it currently makes a\nnon-ff merge when that is pointless that hurts.\n\nThat said, adding the signature from an upstream tag doesn't really\nseem to be hugely useful. I'm not seeing much of an upside, in other\nwords. I'd *expect* that people would pick up upstream tags\nregardless, no?\n\n Linus\n"},{"id":"211169","messageId":"7vli9s5ldz.fsf@alter.siamese.dyndns.org","threadId":"33162","inReplyTo":"CA+55aFzWjfFjcRZXBO+edO7f66REA0pOsC3iZ2vYdHrkcovnHA@mail.gmail.com","subject":"Re: linux-next: unneeded merge in the security tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-12T22:00:24Z","receivedAt":"2013-03-12T22:00:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> That said, adding the signature from an upstream tag doesn't really\n> seem to be hugely useful. I'm not seeing much of an upside, in other\n> words. I'd *expect* that people would pick up upstream tags\n> regardless, no?\n\nYes, their \"git fetch\" will auto-follow, but mergetag embedded in\nthe commit objects will give the history auditable trail the same\nway as the merges you make your downstream. You of course could\nmatch out-of-line tags against back-merges and verify your merges\nwith mergetags, but you do not have to.\n"},{"id":"211192","messageId":"20130313023026.GD16919@thunk.org","threadId":"33162","inReplyTo":"7vtxog5msj.fsf@alter.siamese.dyndns.org","subject":"Re: linux-next: unneeded merge in the security tree","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2013-03-13T02:30:26Z","receivedAt":"2013-03-13T02:30:26Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Tue, Mar 12, 2013 at 02:30:04PM -0700, Junio C Hamano wrote:\n> Theodore Ts'o writes:\n> \n> > [remote \"origin\"]\n> > \turl = git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n> > \tfetch = +refs/heads/master:refs/heads/master\n> > \tmergeoptions = --ff-only\n> >\n> \n> Is there an escape hatch for that rare case? IOW, how does a\n> submaintainer who configured the above to override --ff-only?\n\nHmm, maybe we would need to add a --no-ff-only? Or they could just\ndo:\n\n\tgit fetch origin\n\tgit merge FETCH_HEAD\n\nOn Tue, Mar 12, 2013 at 02:28:39PM -0700, Linus Torvalds wrote:\n>\n> Of course, I'm not really sure if we want to list the flags. Maybe\n> it's better to just introduce the notion of \"upstream\" directly, and\n> make that a flag, and make \"origin\" default to that when you clone.\n> And then have git use different heurstics for pulling upstream (like\n> warning by default when doing a back-merge, perhaps?)\n\nWhat if git automaticallly set up the origin branch to have a certain\nset of mergeoptions by default? That would probably be right for most\nusers, but it makes it obvious what's going on when they take a look\nat the .git/config file, and doesn't make the remote that happens to\nhave the name \"origin\" as having certain magic properties. Using a\nset of mergeoptions would also be bit more general, and might have\napplications in the future.\n\n \t \t \t \t \t - Ted\n"},{"id":"211193","messageId":"7v38w056pk.fsf@alter.siamese.dyndns.org","threadId":"33162","inReplyTo":"20130313023026.GD16919@thunk.org","subject":"Re: linux-next: unneeded merge in the security tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-13T03:17:27Z","receivedAt":"2013-03-13T03:17:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Theodore Ts'o writes:\n\n> On Tue, Mar 12, 2013 at 02:30:04PM -0700, Junio C Hamano wrote:\n>> Theodore Ts'o writes:\n>> \n>> > [remote \"origin\"]\n>> > \turl = git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n>> > \tfetch = +refs/heads/master:refs/heads/master\n>> > \tmergeoptions = --ff-only\n>> >\n>> \n>> Is there an escape hatch for that rare case? IOW, how does a\n>> submaintainer who configured the above to override --ff-only?\n>\n> Hmm, maybe we would need to add a --no-ff-only? Or they could just\n> do:\n>\n> \tgit fetch origin\n> \tgit merge FETCH_HEAD\n\nHmm, neither feel quite nice.\n\nI haven't heard any comments on my alternative proposal, by the\nway. Did the message get lost?\n"}]}