{"thread":{"id":"50169","subject":"Feature request: --preserve-merges to add \"exec git merge ...\" instead of \"pick ...\"","startedAt":"2019-01-07T14:02:29Z","lastAt":"2019-01-08T18:38:07Z","messageCount":5,"participants":["Andreas Hennings","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"366256","messageId":"CAH0Uv3Eu7bGSVaJKu6kDjp0BPRe0yROucDfJ8QHV3X_ZjNJT7g@mail.gmail.com","threadId":"50169","inReplyTo":null,"subject":"Feature request: --preserve-merges to add \"exec git merge ...\" instead of \"pick ...\"","fromName":"Andreas Hennings","fromEmail":"andreas@dqxtech.net","sentAt":"2019-01-07T14:02:14Z","receivedAt":"2019-01-07T14:02:29Z","isPatch":false,"sender":{"key":"andreas@dqxtech.net","avatar":null},"body":"Hello,\n(this is my first message on this list, so hello everybody. I hope I\nfound the correct channel.)\n\nI recently discovered the --preserve-merges option in git rebase,\nI think it is nice, but it does not always do what I intend.\n\nI am proposing a variation of this option which would behave differently.\n\n## Use case\n\nWe have an acceptance branch that is frequently rebased on master.\nAt any given time, the acceptance branch should start with master, and\nthen merge in those feature branches that were selected for acceptance\ntesting.\nNobody is supposed to work on acceptance, it is only meant for\ndeployment on the acceptance server.\n\nThis means we need a rebase operation where:\n- The commits of the acceptance branch itself are being replaced.\n- The commits of the feature branches remain as they are.\n\nA \"git rebase --preserve-merges\" almost does this, but not really.\n\n## Proposal\n\nAdd a new option for rebase, similar to --preserve-merges, where:\nInstead of \"git pick MERGE_COMMIT\", we get this line in the rebase\neditor (if using the -i option):\nexec git merge MERGE_COMMIT^2 -m\"Merge FEATURE_BRANCH into acceptance.\"\n\nIn --interactive / -i mode, the developer can leave these lines as\nthey are, or replace them manually to merge a more recent version of\nthe feature branch.\nE.g. replace this\nexec git merge MERGE_COMMIT^2 -m\"Merge FEATURE_BRANCH into acceptance.\"\nwith this\nexec git merge FEATURE_BRANCH_RECENT\n\nThis would achieve the behavior as described in \"Use case\".\nI have not thought about a name for this option yet, I first want to\nsee some general feedback.\n\nPossibly related:\nhttps://public-inbox.org/git/87y3jtqdyg.fsf@javad.com/\nI think the author of this RFC has different expectations what a\nrebase should do, so it is not really the same.\n\n\n------------\n\nI hope this was the correct way to propose this kind of feature. If\nnot, let me know where I can find more information.\n\nGreetings,\nAndreas Hennings\nhttps://github.com/donquixote\n"},{"id":"366261","messageId":"xmqq36q4berk.fsf@gitster-ct.c.googlers.com","threadId":"50169","inReplyTo":"CAH0Uv3Eu7bGSVaJKu6kDjp0BPRe0yROucDfJ8QHV3X_ZjNJT7g@mail.gmail.com","subject":"Re: Feature request: --preserve-merges to add \"exec git merge ...\" instead of \"pick ...\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-01-07T16:42:39Z","receivedAt":"2019-01-07T16:42:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Hennings writes:\n\n> This means we need a rebase operation where:\n> - The commits of the acceptance branch itself are being replaced.\n> - The commits of the feature branches remain as they are.\n>\n> A \"git rebase --preserve-merges\" almost does this, but not really.\n\nThis wished-for feature sounds to me more like the \"first-parent\"\nmode that has been discussed a few times in the past but never\nmaterialized.\n\nThe preserve-merges mode is getting abandoned by the original author\nas unsalvageable. Have you tried the rebase-merges mode? That may\nlet you choose replaying only the merge commits on the acceptance\nbranch without touching the tips of the feature branches getting\nmerged.\n"},{"id":"366288","messageId":"CAH0Uv3FRq0JiXWx9Ow1EhKrYB4OTM-9Fpox7FvZ3tC6J6toEsw@mail.gmail.com","threadId":"50169","inReplyTo":"xmqq36q4berk.fsf@gitster-ct.c.googlers.com","subject":"Re: Feature request: --preserve-merges to add \"exec git merge ...\" instead of \"pick ...\"","fromName":"Andreas Hennings","fromEmail":"andreas@dqxtech.net","sentAt":"2019-01-07T21:12:21Z","receivedAt":"2019-01-07T21:12:36Z","isPatch":false,"sender":{"key":"andreas@dqxtech.net","avatar":null},"body":"It sounds good!\nI was using git version 2.7.4 all the time. I should have checked\nbefore posting here :)\nNow trying 2.20.1\n\nFrom \"git help rebase\":\n\n By default, or when no-rebase-cousins was specified,\ncommits which do not have as direct ancestor will keep\ntheir\n original branch point, i.e. commits that would be excluded\nby gitlink:git-log[1]'s --ancestry-path option will keep their\n original ancestry by default. If the rebase-cousins mode is\nturned on, such commits are instead rebased onto (or\n , if specified).\n\nI am not sure if this criterion (which ancestors it has) will always\nproduce the behavior I am looking for.\nI will have to experiment a bit.\n\nThanks for now, I will post again with new thoughts once I have done\nsome experiments.\n\nOn Mon, 7 Jan 2019 at 17:42, Junio C Hamano wrote:\n>\n> Andreas Hennings writes:\n>\n> > This means we need a rebase operation where:\n> > - The commits of the acceptance branch itself are being replaced.\n> > - The commits of the feature branches remain as they are.\n> >\n> > A \"git rebase --preserve-merges\" almost does this, but not really.\n>\n> This wished-for feature sounds to me more like the \"first-parent\"\n> mode that has been discussed a few times in the past but never\n> materialized.\n>\n> The preserve-merges mode is getting abandoned by the original author\n> as unsalvageable. Have you tried the rebase-merges mode? That may\n> let you choose replaying only the merge commits on the acceptance\n> branch without touching the tips of the feature branches getting\n> merged.\n"},{"id":"366351","messageId":"CAH0Uv3F4q0oPG2O58eTV5n+5eZcxHK9acGMX+4F4LTm1JATfhg@mail.gmail.com","threadId":"50169","inReplyTo":"CAH0Uv3FRq0JiXWx9Ow1EhKrYB4OTM-9Fpox7FvZ3tC6J6toEsw@mail.gmail.com","subject":"Re: Feature request: --preserve-merges to add \"exec git merge ...\" instead of \"pick ...\"","fromName":"Andreas Hennings","fromEmail":"andreas@dqxtech.net","sentAt":"2019-01-08T18:13:31Z","receivedAt":"2019-01-08T18:13:46Z","isPatch":false,"sender":{"key":"andreas@dqxtech.net","avatar":null},"body":"I tried this option after upgrading my git.\nUnfortunately, no matter which variation I use, it still attempts to\nrebase most or all of the feature branches before merging them.\nPossibly depending on their ancestry.\n\n\nOn Mon, 7 Jan 2019 at 22:12, Andreas Hennings wrote:\n>\n> It sounds good!\n> I was using git version 2.7.4 all the time. I should have checked\n> before posting here :)\n> Now trying 2.20.1\n>\n> From \"git help rebase\":\n>\n> By default, or when no-rebase-cousins was specified,\n> commits which do not have as direct ancestor will keep\n> their\n> original branch point, i.e. commits that would be excluded\n> by gitlink:git-log[1]'s --ancestry-path option will keep their\n> original ancestry by default. If the rebase-cousins mode is\n> turned on, such commits are instead rebased onto (or\n> , if specified).\n>\n> I am not sure if this criterion (which ancestors it has) will always\n> produce the behavior I am looking for.\n> I will have to experiment a bit.\n>\n> Thanks for now, I will post again with new thoughts once I have done\n> some experiments.\n>\n> On Mon, 7 Jan 2019 at 17:42, Junio C Hamano wrote:\n> >\n> > Andreas Hennings writes:\n> >\n> > > This means we need a rebase operation where:\n> > > - The commits of the acceptance branch itself are being replaced.\n> > > - The commits of the feature branches remain as they are.\n> > >\n> > > A \"git rebase --preserve-merges\" almost does this, but not really.\n> >\n> > This wished-for feature sounds to me more like the \"first-parent\"\n> > mode that has been discussed a few times in the past but never\n> > materialized.\n> >\n> > The preserve-merges mode is getting abandoned by the original author\n> > as unsalvageable. Have you tried the rebase-merges mode? That may\n> > let you choose replaying only the merge commits on the acceptance\n> > branch without touching the tips of the feature branches getting\n> > merged.\n"},{"id":"366355","messageId":"xmqqd0p7571y.fsf@gitster-ct.c.googlers.com","threadId":"50169","inReplyTo":"CAH0Uv3F4q0oPG2O58eTV5n+5eZcxHK9acGMX+4F4LTm1JATfhg@mail.gmail.com","subject":"Re: Feature request: --preserve-merges to add \"exec git merge ...\" instead of \"pick ...\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-01-08T18:38:01Z","receivedAt":"2019-01-08T18:38:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Hennings writes:\n\n> I tried this option after upgrading my git.\n> Unfortunately, no matter which variation I use, it still attempts to\n> rebase most or all of the feature branches before merging them.\n> Possibly depending on their ancestry.\n\nYes, I know that. But what I am hoping is that it won't actually\ntouch the commits on the side branches UNLESS you tell in the insn\nsequence to modify them with \"edit\", \"reword\", etc. and instead\nfast-forward them.\n\nOf course, it will allow you to muck with these commits on the side\nbranches, which is a potential source of mistakes.\n"}]}