{"thread":{"id":"37235","subject":"Re: Amending merge commits?","startedAt":"2014-07-28T21:47:41Z","lastAt":"2014-07-30T18:28:23Z","messageCount":10,"participants":["Nico Williams","Sergei Organov","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"246836","messageId":"CAK3OfOjr6ej5VdGU=bLmtag9cca1=ogLxVakCFTMG7b-A2uBiA@mail.gmail.com","threadId":"37235","inReplyTo":null,"subject":"Re: Amending merge commits?","fromName":"Nico Williams","fromEmail":"nico@cryptonector.com","sentAt":"2014-07-28T21:47:41Z","receivedAt":"2014-07-28T21:47:41Z","isPatch":false,"sender":{"key":"nico@cryptonector.com","avatar":null},"body":"On Mon, Jul 28, 2014 at 3:00 PM, Jonathan Nieder wrote:\n> Sergei Organov wrote:\n>\n>> Is there any scenario at all where pull --rebase=true wins over\n>> preserve?\n>\n> Basically always in my book. ;-)\n>\n> When people turn on 'pull --rebase', they are asking for a clean,\n> simplified history where their changes are small discrete patches in a\n> clump on top of upstream.\n\n+1. Words to develop by.\n\nThere are exceptions. E.g., when you pull commits from multiple\n[forked] upstreams, then you can't keep your local commits on top.\n\nThat exception aside, keeping all local commits \"on top\" by always\nrebasing them onto the upstream is extremely useful: a) in simplifying\nconflict resolution, b) making it easy to identify as-yet-unintegrated\nlocal commits, c) making it easy to contribute local commits.\n\nNico\n--\n"},{"id":"246887","messageId":"87r4147agk.fsf@osv.gnss.ru","threadId":"37235","inReplyTo":"CAK3OfOjr6ej5VdGU=bLmtag9cca1=ogLxVakCFTMG7b-A2uBiA@mail.gmail.com","subject":"Re: Amending merge commits?","fromName":"Sergei Organov","fromEmail":"osv@javad.com","sentAt":"2014-07-29T09:58:35Z","receivedAt":"2014-07-29T09:58:35Z","isPatch":false,"sender":{"key":"osv@javad.com","avatar":null},"body":"Nico Williams writes:\n\n> On Mon, Jul 28, 2014 at 3:00 PM, Jonathan Nieder wrote:\n>> Sergei Organov wrote:\n>>\n>>> Is there any scenario at all where pull --rebase=true wins over\n>>> preserve?\n>>\n>> Basically always in my book. ;-)\n>>\n>> When people turn on 'pull --rebase', they are asking for a clean,\n>> simplified history where their changes are small discrete patches in a\n>> clump on top of upstream.\n>\n> +1. Words to develop by.\n>\n> There are exceptions. E.g., when you pull commits from multiple\n> [forked] upstreams, then you can't keep your local commits on top.\n>\n> That exception aside, keeping all local commits \"on top\" by always\n> rebasing them onto the upstream is extremely useful: a) in simplifying\n> conflict resolution, b) making it easy to identify as-yet-unintegrated\n> local commits, c) making it easy to contribute local commits.\n\nBut 'pull --rebase=preserve' does rebase local commits onto the\nupstream, and result is exactly the same as 'pull --rebase=true', unless\nyou have some of your own merges to be rebased. That's where the\ndifference between these two options appears. It's --rebase=false that\nperforms merges rather than rebase.\n\nOverall, I still can't see where '--rebase=true' wins over\n'--rebase=preserve'.\n\n-- \nSergey.\n"},{"id":"246921","messageId":"CAK3OfOhFzbUA7gZbox84W=VC+0aSuiNc-XRP_MTyYy1UeFFzZQ@mail.gmail.com","threadId":"37235","inReplyTo":"87r4147agk.fsf@osv.gnss.ru","subject":"Re: Amending merge commits?","fromName":"Nico Williams","fromEmail":"nico@cryptonector.com","sentAt":"2014-07-29T15:44:11Z","receivedAt":"2014-07-29T15:44:11Z","isPatch":false,"sender":{"key":"nico@cryptonector.com","avatar":null},"body":"On Tue, Jul 29, 2014 at 4:58 AM, Sergei Organov wrote:\n> Nico Williams writes:\n>> That exception aside, keeping all local commits \"on top\" by always\n>> rebasing them onto the upstream is extremely useful: a) in simplifying\n>> conflict resolution, b) making it easy to identify as-yet-unintegrated\n>> local commits, c) making it easy to contribute local commits.\n>\n> But 'pull --rebase=preserve' does rebase local commits onto the\n> upstream, and result is exactly the same as 'pull --rebase=true', unless\n> you have some of your own merges to be rebased. That's where the\n> difference between these two options appears. It's --rebase=false that\n> performs merges rather than rebase.\n\nLocal merge commits mean that you either didn't rebase to keep all\nyour local commits on top of the upstream, or that you have multiple\nupstreams (the example exception I gave).\n\nConversely, if you always rebase your local commits on top of the\nupstream then you won't have merge commits to worry about.\n\nNico\n--\n"},{"id":"246938","messageId":"DFE66A48CBC646E795B3B4A0903AB19E@PhilipOakley","threadId":"37235","inReplyTo":"CAK3OfOhFzbUA7gZbox84W=VC+0aSuiNc-XRP_MTyYy1UeFFzZQ@mail.gmail.com","subject":"Re: Amending merge commits?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2014-07-29T19:29:20Z","receivedAt":"2014-07-29T19:29:20Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Nico Williams\" \n> On Tue, Jul 29, 2014 at 4:58 AM, Sergei Organov wrote:\n>> Nico Williams writes:\n>>> That exception aside, keeping all local commits \"on top\" by always\n>>> rebasing them onto the upstream is extremely useful: a) in \n>>> simplifying\n>>> conflict resolution, b) making it easy to identify \n>>> as-yet-unintegrated\n>>> local commits, c) making it easy to contribute local commits.\n>>\n>> But 'pull --rebase=preserve' does rebase local commits onto the\n>> upstream, and result is exactly the same as 'pull --rebase=true', \n>> unless\n>> you have some of your own merges to be rebased. That's where the\n>> difference between these two options appears. It's --rebase=false \n>> that\n>> performs merges rather than rebase.\n>\n> Local merge commits mean that you either didn't rebase to keep all\n> your local commits on top of the upstream, or that you have multiple\n> upstreams (the example exception I gave).\n>\n> Conversely, if you always rebase your local commits on top of the\n> upstream then you won't have merge commits to worry about.\n>\nWhilst it may not be \"the Git Way\", I'd expect that in many less well \ninformed companies, the need to keep merge commits fom other lines of \ndevelopment would be quite a common (political ) technique where some \npreparatory branch needs to be merged in before one's feature can be \ncompleted (similar to all those cases on the list when folk say 'builds \non top of xy's commit deadbeaf)\n\nPhilip \n"},{"id":"246943","messageId":"CAK3OfOgZt55+tKv5455Jk-F=buULtftmCasbxHYcxGzppbWcfg@mail.gmail.com","threadId":"37235","inReplyTo":"DFE66A48CBC646E795B3B4A0903AB19E@PhilipOakley","subject":"Re: Amending merge commits?","fromName":"Nico Williams","fromEmail":"nico@cryptonector.com","sentAt":"2014-07-29T20:19:14Z","receivedAt":"2014-07-29T20:19:14Z","isPatch":false,"sender":{"key":"nico@cryptonector.com","avatar":null},"body":"On Tue, Jul 29, 2014 at 2:29 PM, Philip Oakley wrote:\n> From: \"Nico Williams\" \n>> Local merge commits mean that you either didn't rebase to keep all\n>> your local commits on top of the upstream, or that you have multiple\n>> upstreams (the example exception I gave).\n>>\n>> Conversely, if you always rebase your local commits on top of the\n>> upstream then you won't have merge commits to worry about.\n>>\n> Whilst it may not be \"the Git Way\", I'd expect that in many less well\n> informed companies, the need to keep merge commits fom other lines of\n> development would be quite a common (political ) technique where some\n> preparatory branch needs to be merged in before one's feature can be\n> completed (similar to all those cases on the list when folk say 'builds on\n> top of xy's commit deadbeaf)\n\nThe way we did this at Sun, first with Teamware, then later with\nMercurial, was as follows:\n\n - \"projects\" kept their own clone repos of the upstream\n - engineers working on a project cloned the project repo (\"project gate\")\n - engineers pushed/pulled to/from the project gate\n - each project gate had a gatekeeper whose job it was to periodically\nrebase onto the latest upstream\n - then engineers would rebase onto the new project gate\n\nNo \"merge turds\" (Sun speak) were ever allowed in any upstream,\nwhether a project gate or the ultimate upstream. All commits had to\nbe organized according to specific rules, and squashed. These rules\napplied at the project gate and in the upstream.\n\n - when the project was ready for integration the gatekeeper would\nrebase and squash as necessary, then push to the upstream\n\n(I'm eliding some details. In particular when an intermediate\nupstream rebased the previous head was left available as a \"snapshot\"\nto make the equivalent of git rebase --onto possible.)\n\nThe upshot was: all local commits were always on top of whatever the\nnext upstream in the chain was. Always. No merge commits ever.\n\nThat workflow works just fine with git. It worked really well at Sun\n(with thousands of engineers working on Solaris alone). And it should\nwork well for anyone who doesn't have two or more forked upstreams to\nfollow.\n\nNico\n--\n"},{"id":"246949","messageId":"9EFB89B516004883AC0FD774595B84E7@PhilipOakley","threadId":"37235","inReplyTo":"CAK3OfOgZt55+tKv5455Jk-F=buULtftmCasbxHYcxGzppbWcfg@mail.gmail.com","subject":"Re: Amending merge commits?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2014-07-29T21:38:57Z","receivedAt":"2014-07-29T21:38:57Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Nico Williams\" \n> On Tue, Jul 29, 2014 at 2:29 PM, Philip Oakley \n> wrote:\n>> From: \"Nico Williams\" \n>>> Local merge commits mean that you either didn't rebase to keep all\n>>> your local commits on top of the upstream, or that you have multiple\n>>> upstreams (the example exception I gave).\n>>>\n>>> Conversely, if you always rebase your local commits on top of the\n>>> upstream then you won't have merge commits to worry about.\n>>>\n>> Whilst it may not be \"the Git Way\", I'd expect that in many less well\n>> informed companies, the need to keep merge commits fom other lines of\n>> development would be quite a common (political ) technique where some\n>> preparatory branch needs to be merged in before one's feature can be\n>> completed (similar to all those cases on the list when folk say \n>> 'builds on\n>> top of xy's commit deadbeaf)\n>\n> The way we did this at Sun, first with Teamware, then later with\n> Mercurial, was as follows:\n>\n> - \"projects\" kept their own clone repos of the upstream\n> - engineers working on a project cloned the project repo (\"project \n> gate\")\n> - engineers pushed/pulled to/from the project gate\n> - each project gate had a gatekeeper whose job it was to periodically\n> rebase onto the latest upstream\n> - then engineers would rebase onto the new project gate\n>\n> No \"merge turds\" (Sun speak) were ever allowed in any upstream,\n> whether a project gate or the ultimate upstream. All commits had to\n> be organized according to specific rules, and squashed. These rules\n> applied at the project gate and in the upstream.\n>\n> - when the project was ready for integration the gatekeeper would\n> rebase and squash as necessary, then push to the upstream\n>\n> (I'm eliding some details. In particular when an intermediate\n> upstream rebased the previous head was left available as a \"snapshot\"\n> to make the equivalent of git rebase --onto possible.)\n>\n> The upshot was: all local commits were always on top of whatever the\n> next upstream in the chain was. Always. No merge commits ever.\n>\n> That workflow works just fine with git.\n\nI'm not saying that it isn't a good technique and can work well. Rather \nI'm saying we should be tolerant of the rules and techniques of others \nwho do have 'merges' in their workflow organisation. They may have a \nvery long QA delay between feature 'done' and feature 'done done tested \nmerged', which requires maintaining merges of done items that aren't yet \nmerged to master. Such techniques are more common in mixed engineering \nthan pure software environments (where engineering rules apply, and \nsoftware has to follow)\n\n> It worked really well at Sun\n> (with thousands of engineers working on Solaris alone). And it should\n> work well for anyone who doesn't have two or more forked upstreams to\n> follow.\n\nI'm just cautious of an accidental one size fits all approach, so the \nability to rebase lines of development which contain merge commits \nshould be possible (with an appropriate and documented option) without \nhidden traps.\n>\nPhilip \n"},{"id":"246950","messageId":"CAK3OfOgsY43oiuUNggS+Tz2zfMKB_eO2U+S2tiNsoYGk5qhn2w@mail.gmail.com","threadId":"37235","inReplyTo":"9EFB89B516004883AC0FD774595B84E7@PhilipOakley","subject":"Re: Amending merge commits?","fromName":"Nico Williams","fromEmail":"nico@cryptonector.com","sentAt":"2014-07-29T22:07:11Z","receivedAt":"2014-07-29T22:07:11Z","isPatch":false,"sender":{"key":"nico@cryptonector.com","avatar":null},"body":"On Tue, Jul 29, 2014 at 4:38 PM, Philip Oakley wrote:\n> From: \"Nico Williams\" \n>> That workflow works just fine with git.\n>\n> I'm not saying that it isn't a good technique and can work well. Rather I'm\n> saying we should be tolerant of the rules and techniques of others who do\n> [...]\n\nSure. I was just giving advice as to how to avoid any problems at\npull time w.r.t. local merge commits.\n\nBetter merge commit handling at pull time might be great (I'd not\nknow; I avoid local merge commits!), but I would still strongly\nrecommend keeping all local commits on top because otherwise you lose\nlocal history. Even if you use -m to set a better commit message, you\nmight prefer to have kept the original N local -now rebased- commits\naround so you can tell what each discrete change was, even if you'll\neventually squash them (you might not squash them all into one).\n\n>> It worked really well at Sun\n>> (with thousands of engineers working on Solaris alone). And it should\n>> work well for anyone who doesn't have two or more forked upstreams to\n>> follow.\n>\n> I'm just cautious of an accidental one size fits all approach, so the\n> ability to rebase lines of development which contain merge commits should be\n> possible (with an appropriate and documented option) without hidden traps.\n\nThus far the only case I've seen where this approach doesn't work _at\nall_ is the case where you have multiple forked upstreams. The only\nother case where it doesn't work is a social problem: rebase allergy.\nFor the repos I maintain I insist on contributed commits applying as\nfast forward merges, or I'll rebase them myself if need be.\n\nNico\n--\n"},{"id":"246957","messageId":"87siljxmnh.fsf@osv.gnss.ru","threadId":"37235","inReplyTo":"CAK3OfOhFzbUA7gZbox84W=VC+0aSuiNc-XRP_MTyYy1UeFFzZQ@mail.gmail.com","subject":"Re: Amending merge commits?","fromName":"Sergei Organov","fromEmail":"osv@javad.com","sentAt":"2014-07-30T08:42:58Z","receivedAt":"2014-07-30T08:42:58Z","isPatch":false,"sender":{"key":"osv@javad.com","avatar":null},"body":"Nico Williams writes:\n\n> On Tue, Jul 29, 2014 at 4:58 AM, Sergei Organov wrote:\n>> Nico Williams writes:\n>>> That exception aside, keeping all local commits \"on top\" by always\n>>> rebasing them onto the upstream is extremely useful: a) in simplifying\n>>> conflict resolution, b) making it easy to identify as-yet-unintegrated\n>>> local commits, c) making it easy to contribute local commits.\n>>\n>> But 'pull --rebase=preserve' does rebase local commits onto the\n>> upstream, and result is exactly the same as 'pull --rebase=true', unless\n>> you have some of your own merges to be rebased. That's where the\n>> difference between these two options appears. It's --rebase=false that\n>> performs merges rather than rebase.\n>\n> Local merge commits mean that you either didn't rebase to keep all\n> your local commits on top of the upstream, or that you have multiple\n> upstreams (the example exception I gave).\n\nI rather have multiple (release) branches on single upstream, say, v2.3\nand v2.4. When something needs to be fixed in 2.3, it's fixed there and\npushed upstream, then, on 2.4, the 2.3 is merged to it, and result is\npushed upstream. When I do this merge, I need to push the merge\nupstream, and this won't work reliably when --rebase=true is acitve\n(through pull.merge=rebase). If nothing changes upstream, I can simply\npush this, and the merge is correctly preserved. However, if somebody\nmakes any changes upstream while I perform the merge, I'll need to pull\nbefore pushing, and this immediately flattens-out my merge, that is\nabsolutely not what is needed here. Or I can simply pull before push,\njust in case, and this flattens history even when there are no any\nchanges upstream!\n\nOnce again, nobody yet gave any clue of when/why pull.merge=preserve\nconfiguration is inferior to pull.merge=rebase, as for all the scenario\nyou seem to care about they bring the same result.\n\n> Conversely, if you always rebase your local commits on top of the\n> upstream then you won't have merge commits to worry about.\n\nWrong. I do alwys rebase my local commits on top of upstream, but I\nstill do have my own merge commits to worry about, as explained above.\n\n-- \nSergey.\n"},{"id":"246978","messageId":"CAK3OfOgcO9dmePtXCu9gUSf2bdQytJf9-RCZDXhv9Gy8UVyDOQ@mail.gmail.com","threadId":"37235","inReplyTo":"87siljxmnh.fsf@osv.gnss.ru","subject":"Re: Amending merge commits?","fromName":"Nico Williams","fromEmail":"nico@cryptonector.com","sentAt":"2014-07-30T17:43:14Z","receivedAt":"2014-07-30T17:43:14Z","isPatch":false,"sender":{"key":"nico@cryptonector.com","avatar":null},"body":"On Wed, Jul 30, 2014 at 3:42 AM, Sergei Organov wrote:\n> Nico Williams writes:\n>> Local merge commits mean that you either didn't rebase to keep all\n>> your local commits on top of the upstream, or that you have multiple\n>> upstreams (the example exception I gave).\n>\n> I rather have multiple (release) branches on single upstream, say, v2.3\n> and v2.4. When something needs to be fixed in 2.3, it's fixed there and\n> pushed upstream, then, on 2.4, the 2.3 is merged to it, and result is\n> pushed upstream. When I do this merge, I need to push the merge\n\nHmm, why not cherry-pick the fix? That's how every project I know\nthat ports fixes across release branches does it.\n\n> upstream, and this won't work reliably when --rebase=true is acitve\n> (through pull.merge=rebase). If nothing changes upstream, I can simply\n> push this, and the merge is correctly preserved. However, if somebody\n> makes any changes upstream while I perform the merge, I'll need to pull\n> before pushing, and this immediately flattens-out my merge, that is\n> absolutely not what is needed here. Or I can simply pull before push,\n> just in case, and this flattens history even when there are no any\n> changes upstream!\n\nDoes this change if you give your merge commits an different commit message?\n\n>> Conversely, if you always rebase your local commits on top of the\n>> upstream then you won't have merge commits to worry about.\n>\n> Wrong. I do alwys rebase my local commits on top of upstream, but I\n> still do have my own merge commits to worry about, as explained above.\n\nIf you cherry-pick the cross-release-branch commits you'll not have a\nmerge commit to worry about.\n\nNico\n--\n"},{"id":"246983","messageId":"877g2uu2ew.fsf@osv.gnss.ru","threadId":"37235","inReplyTo":"CAK3OfOgcO9dmePtXCu9gUSf2bdQytJf9-RCZDXhv9Gy8UVyDOQ@mail.gmail.com","subject":"Re: Amending merge commits?","fromName":"Sergei Organov","fromEmail":"osv@javad.com","sentAt":"2014-07-30T18:28:23Z","receivedAt":"2014-07-30T18:28:23Z","isPatch":false,"sender":{"key":"osv@javad.com","avatar":null},"body":"Nico Williams writes:\n\n> On Wed, Jul 30, 2014 at 3:42 AM, Sergei Organov wrote:\n>> Nico Williams writes:\n>>> Local merge commits mean that you either didn't rebase to keep all\n>>> your local commits on top of the upstream, or that you have multiple\n>>> upstreams (the example exception I gave).\n>>\n>> I rather have multiple (release) branches on single upstream, say, v2.3\n>> and v2.4. When something needs to be fixed in 2.3, it's fixed there and\n>> pushed upstream, then, on 2.4, the 2.3 is merged to it, and result is\n>> pushed upstream. When I do this merge, I need to push the merge\n>\n> Hmm, why not cherry-pick the fix? That's how every project I know\n> that ports fixes across release branches does it.\n\nCherry-pick? Why bother? What problem do we solve, having no merges\nwhatsoever? Why? GIT is so good at merges!\n\nMy impression is that people mostly rather do topic branches, and merge\nthem wherever they need the fixes, no?\n\n>> upstream, and this won't work reliably when --rebase=true is acitve\n>> (through pull.merge=rebase). If nothing changes upstream, I can simply\n>> push this, and the merge is correctly preserved. However, if somebody\n>> makes any changes upstream while I perform the merge, I'll need to pull\n>> before pushing, and this immediately flattens-out my merge, that is\n>> absolutely not what is needed here. Or I can simply pull before push,\n>> just in case, and this flattens history even when there are no any\n>> changes upstream!\n>\n> Does this change if you give your merge commits an different commit\n> message?\n\nDifferent from what? I'm almost sure commit message has nothing to do\nwith it. Please refer to this explanation to see for yourself how git\nbehaves when rebasing:\n\nhttp://www.mail-archive.com/git%40vger.kernel.org/msg55605.html\n\n>\n>>> Conversely, if you always rebase your local commits on top of the\n>>> upstream then you won't have merge commits to worry about.\n>>\n>> Wrong. I do alwys rebase my local commits on top of upstream, but I\n>> still do have my own merge commits to worry about, as explained above.\n>\n> If you cherry-pick the cross-release-branch commits you'll not have a\n> merge commit to worry about.\n\nI fail to see why do you consider merge commits to be an evil, really. I\ndidn't think about cherry-picking carefully, but I don't feel\ncherry-picking is the best tool for the job here. I suspect random\ncherry-picking would create a mess, sooner or later.\n\n-- \nSergey.\n"}]}