{"thread":{"id":"26687","subject":"Is there a way to add a default `--squash` flag for all merges into a head?","startedAt":"2011-03-07T19:28:09Z","lastAt":"2011-03-10T19:38:21Z","messageCount":9,"participants":["Dun Peal","Andreas Schwab","Jay Soffian","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"162935","messageId":"9f02bed0-fa18-46b1-a3d3-346e1cc7dc01@k15g2000prk.googlegroups.com","threadId":"26687","inReplyTo":null,"subject":"Is there a way to add a default `--squash` flag for all merges into a head?","fromName":"Dun Peal","fromEmail":"dunpealer@gmail.com","sentAt":"2011-03-07T19:28:09Z","receivedAt":"2011-03-07T19:28:09Z","isPatch":false,"sender":{"key":"dunpealer@gmail.com","avatar":"https://gravatar.com/avatar/42f3e6a1166eb44e33f24c20ccbe809fa8591413f366dfe3755c8a8d4935ace9?d=mp&s=160"},"body":"Hi,\n\nOur main Git repository supports a lot of developers working on\nmultiple branches from master. Whenever the work on a branch is\nfinished, the branch-owning developer(s) merge it back to master. That\nmerge is always done with a `--squash` flag to avoid the 50+ levels\ndeep graph we would end up with if everyone just used a true merge.\n\nThere's a configuration feaute `branch..rebase` for specifying\nthat all merges into a branch (master in this case) would be done by\nrebase, so I was expecting a similar feature for always squashing back\n(since some developers may forget to add the flag). Unfortunately, I\ncouldn't find it. Does it exist?\n\nThanks, D.\n"},{"id":"162938","messageId":"m2r5aibpsl.fsf@igel.home","threadId":"26687","inReplyTo":"9f02bed0-fa18-46b1-a3d3-346e1cc7dc01@k15g2000prk.googlegroups.com","subject":"Re: Is there a way to add a default `--squash` flag for all merges into a head?","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2011-03-07T21:10:02Z","receivedAt":"2011-03-07T21:10:02Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Dun Peal writes:\n\n> There's a configuration feaute `branch..rebase` for specifying\n> that all merges into a branch (master in this case) would be done by\n> rebase\n\nThat's not what it means. It means that a \"git pull\" is implicitly \"git\npull --rebase\". But if you do an explict merge it will not look at that\nconfig setting.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"162941","messageId":"b98e837f-a0ae-4061-aa09-b4d30e3b0522@b13g2000prf.googlegroups.com","threadId":"26687","inReplyTo":"m2r5aibpsl.fsf@igel.home","subject":"Re: Is there a way to add a default `--squash` flag for all merges into a head?","fromName":"Dun Peal","fromEmail":"dunpealer@gmail.com","sentAt":"2011-03-07T21:48:46Z","receivedAt":"2011-03-07T21:48:46Z","isPatch":false,"sender":{"key":"dunpealer@gmail.com","avatar":"https://gravatar.com/avatar/42f3e6a1166eb44e33f24c20ccbe809fa8591413f366dfe3755c8a8d4935ace9?d=mp&s=160"},"body":"Sigh. You're right, what a silly man I am!!!\n\nI assume there's no way to do what I want, except maybe encourage\neveryone to use an alias for `git merge` that includes the flag.\n\nThanks, D.\n\nOn Mar 7, 3:10 pm, Andreas Schwab wrote:\n> Dun Peal writes:\n> > There's a configuration feaute `branch..rebase` for specifying\n> > that all merges into a branch (master in this case) would be done by\n> > rebase\n>\n> That's not what it means.  It means that a \"git pull\" is implicitly \"git\n> pull --rebase\".  But if you do an explict merge it will not look at that\n> config setting.\n>\n> Andreas.\n>\n> --\n> Andreas Schwab, sch...@linux-m68k.org\n> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5\n> \"And now for something completely different.\"\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majord...@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"162963","messageId":"AANLkTinmdQ6r8cBDsFjXR+KLGeZR1-yeu7h9R=X0+1PG@mail.gmail.com","threadId":"26687","inReplyTo":"9f02bed0-fa18-46b1-a3d3-346e1cc7dc01@k15g2000prk.googlegroups.com","subject":"Re: Is there a way to add a default `--squash` flag for all merges into a head?","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-03-08T07:29:38Z","receivedAt":"2011-03-08T07:29:38Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Mar 7, 2011 at 2:28 PM, Dun Peal wrote:\n> There's a configuration feaute `branch..rebase` for specifying\n> that all merges into a branch (master in this case) would be done by\n> rebase, so I was expecting a similar feature for always squashing back\n> (since some developers may forget to add the flag). Unfortunately, I\n> couldn't find it. Does it exist?\n\nTry:\n\n $ git config branch..mergeoptions --squash\n\nj.\n"},{"id":"163006","messageId":"7vr5ahe7jc.fsf@alter.siamese.dyndns.org","threadId":"26687","inReplyTo":"b98e837f-a0ae-4061-aa09-b4d30e3b0522@b13g2000prf.googlegroups.com","subject":"Re: Is there a way to add a default `--squash` flag for all merges into a head?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-08T19:28:23Z","receivedAt":"2011-03-08T19:28:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dun Peal writes:\n\n> Sigh. You're right, what a silly man I am!!!\n>\n> I assume there's no way to do what I want, except maybe encourage\n> everyone to use an alias for `git merge` that includes the flag.\n\nI have a strong suspicion that it is not really what you want to always\nuse --squash merge, and everybody forced (or \"encouraged\") by you to do so\nwould hate you in the end.\n\nThe solution to whatever problem you are trying to solve should not be to\ndiscard one of the most valuable information git keeps track of to avoid\nthe CVS/(old)SVN mess when performing repeated merges with a branch.\n\nI also suspect that you might be delighted by \"log --first-parent -m\".\n"},{"id":"163067","messageId":"5aad866e-38e6-4f0e-a942-97cc174651bb@o14g2000prb.googlegroups.com","threadId":"26687","inReplyTo":"7vr5ahe7jc.fsf@alter.siamese.dyndns.org","subject":"Re: Is there a way to add a default `--squash` flag for all merges into a head?","fromName":"Dun Peal","fromEmail":"dunpealer@gmail.com","sentAt":"2011-03-09T18:38:17Z","receivedAt":"2011-03-09T18:38:17Z","isPatch":false,"sender":{"key":"dunpealer@gmail.com","avatar":"https://gravatar.com/avatar/42f3e6a1166eb44e33f24c20ccbe809fa8591413f366dfe3755c8a8d4935ace9?d=mp&s=160"},"body":"On Mar 8, 1:28pm, Junio C Hamano wrote:\n> The solution to whatever problem you are trying to solve should not be to\n> discard one of the most valuable information git keeps track of to avoid\n> the CVS/(old)SVN mess when performing repeated merges with a branch.\n\nJunio, this seems viable precisely because we generally don't perform\nrepeated merges between the same heads.\n\nAll of our branches right now are feature branches of master, whose\nshort lives end with a single merge back. Thus, merging back as a\nsingle patch implementing that single feature is ideal: the branch was\nonly created to implement the feature, so by definition all of its\nindividual commits are intermediary, and once the final feature state\nis achieved, the incremental steps leading to it are not interesting\nat all - they're just noise!\n\nWhy would John care that while implementing feature X, Jill committed\nher half-state Y so she can go home, or made and fixed typo Z ? In\nfact, why would Jill care a day, let a lone a couple of months, after\nX was completed and merged to master?\n\nThe noisy, needless nature of these commits is further emphasized by\nthe default behavior of commit graph visualizers to display them in\nfull rather than collapse them. We have over 80 developers working on\nall major operating systems, and using a variety of tools on each.\n`log --first-parent` is nice, but my developers also use gitk, gitg,\ngitx, GitExtensions, and TortoiseGit.\n\nFinally, we are planning to integrate a few key long-lived branches,\nfor example a 'bleeding_edge' branch that everyone commits to, and\ngets periodically merged into master by a technical lead. The\ncollapsing behavior a-la `--first-parent` may not always be desirable\nonce we start doing that, but if you turn it off without mandating\nsquashes, master's history becomes a mess of numerous feature-branch\nmerges, with all of their non-informative intermediary commits.\n\nHope that makes sense, .D\n"},{"id":"163070","messageId":"7v7hc8aybn.fsf@alter.siamese.dyndns.org","threadId":"26687","inReplyTo":"5aad866e-38e6-4f0e-a942-97cc174651bb@o14g2000prb.googlegroups.com","subject":"Re: Is there a way to add a default `--squash` flag for all merges into a head?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-09T19:27:56Z","receivedAt":"2011-03-09T19:27:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dun Peal writes:\n\n> All of our branches right now are feature branches of master, whose\n> short lives end with a single merge back. Thus, merging back as a\n> single patch implementing that single feature is ideal: the branch was\n> only created to implement the feature, so by definition all of its\n> individual commits are intermediary, and once the final feature state\n> is achieved, the incremental steps leading to it are not interesting\n> at all - they're just noise!\n\nYou sounds as if none of your developers make mistakes and your reviewers\nare always so perfect that you have absolute confidence that all the\npossible bugs are killed in these feature branches before they are merged\nto the master.\n\nThat does not sound like a real world to me, though. When a fix or tweak\nis needed for codepaths introduced by these feature branches after they\nare merged to master, the cleanest thing to do is to queue the fix on top\nof the branch that needs that fix or tweak, and merge that to master.\n\nOf course, you can choose to abandon these feature branches that are\npotentially buggy and fork a fix branch from the master branch that was\ncurrent when the bug happened to be discovered. But that would make the\nbackporting bugfixes (or feature tweaks for that matter) to anything older\na lot harder.\n\n> Why would John care that while implementing feature X, Jill committed\n> her half-state Y so she can go home, or made and fixed typo Z ? In\n> fact, why would Jill care a day, let a lone a couple of months, after\n> X was completed and merged to master?\n\nWho is merging half-state to 'master' or merging 'master' back to the\nfeature branches? I don't think any of the above relates to the topic of\n'merge --squash' anyway...\n"},{"id":"163076","messageId":"cb5f3a7a-cc84-4ec9-8d08-87436f8af044@k15g2000prk.googlegroups.com","threadId":"26687","inReplyTo":"7v7hc8aybn.fsf@alter.siamese.dyndns.org","subject":"Re: Is there a way to add a default `--squash` flag for all merges into a head?","fromName":"Dun Peal","fromEmail":"dunpealer@gmail.com","sentAt":"2011-03-09T20:11:54Z","receivedAt":"2011-03-09T20:11:54Z","isPatch":false,"sender":{"key":"dunpealer@gmail.com","avatar":"https://gravatar.com/avatar/42f3e6a1166eb44e33f24c20ccbe809fa8591413f366dfe3755c8a8d4935ace9?d=mp&s=160"},"body":"On Mar 9, 1:27 pm, Junio C Hamano wrote:\n> Dun Peal writes:\n> That does not sound like a real world to me, though. When a fix or tweak\n> is needed for codepaths introduced by these feature branches after they\n> are merged to master, the cleanest thing to do is to queue the fix on top\n> of the branch that needs that fix or tweak, and merge that to master.\n>\n> Of course, you can choose to abandon these feature branches that are\n> potentially buggy and fork a fix branch from the master branch that was\n> current when the bug happened to be discovered. But that would make the\n> backporting bugfixes (or feature tweaks for that matter) to anything older\n> a lot harder.\n\nThat's a good point if feature branches may eventually get merged into\nother branches, e.g. release branches. Our case is simpler: a feature\nbranch that branched off master will only get merged back to master,\nusually in one merge action that ends the branch. Therefore any future\nfixes or updates to content that got merged like that can properly be\ncommitted directly to master.\n\nOf course, if we did need to merge the feature independently into\nother branches, the squashed branch and any future updates to it would\nhave to be manually cherry-picked - an error prone process that\nforgoes many amenities that Git offers for this procedure. However,\nsince we do not have such a need, might as well optimize for commit\ngraph simplicity.\n\nWe probably could find ways to deal with a ~50-level-deep commit graph\n(composed of 1 master and ~49 feature branches), but if we can instead\ndeal with a single-level-deep one (or 2-3 levels when we introduce a\ncouple of long-running branches), why shouldn't we?\n\n> > Why would John care that while implementing feature X, Jill committed\n> > her half-state Y so she can go home, or made and fixed typo Z? In\n> > fact, why would Jill care a day, let a lone a couple of months, after\n> > X was completed and merged to master?\n>\n> Who is merging half-state to 'master' or merging 'master' back to the\n> feature branches? I don't think any of the above relates to the topic of\n> 'merge --squash' anyway...\n\nIf Jill merged her branch X back to master with no squashing, half-\nstate Y which got committed in X gets merged to master as well.\n\nHalf-states like Y get committed to feature branches all the time,\nsince those branches are private, never get deployed in production or\neven built by the continuous integration server; the feature branch is\nall about developer convenience, and we're only strict about what he\nmerges back into master.\n\nOf course, Jill can selectively squash with `rebase -i` X to a more\npresentable form before merging it back to master. But if she's\nalready squashing, why not use the ultimate, simplest squash offered\nby `rebase --squash`, as it happens to perfectly fit the purpose of\nour short-term feature branches?\n\nD.\n"},{"id":"163170","messageId":"5a2ac540-481e-49e6-9e2e-eb410ba483e0@w9g2000prg.googlegroups.com","threadId":"26687","inReplyTo":"AANLkTinmdQ6r8cBDsFjXR+KLGeZR1-yeu7h9R=X0+1PG@mail.gmail.com","subject":"Re: Is there a way to add a default `--squash` flag for all merges into a head?","fromName":"Dun Peal","fromEmail":"dunpealer@gmail.com","sentAt":"2011-03-10T19:38:21Z","receivedAt":"2011-03-10T19:38:21Z","isPatch":false,"sender":{"key":"dunpealer@gmail.com","avatar":"https://gravatar.com/avatar/42f3e6a1166eb44e33f24c20ccbe809fa8591413f366dfe3755c8a8d4935ace9?d=mp&s=160"},"body":"On Mar 8, 1:29 am, Jay Soffian wrote:\n> Try:\n>\n>   $ git config branch..mergeoptions --squash\n\nThanks, that works great and answers our need. Thanks to Junio as well\nfor the thorough discussion of our workflow.\n\n.D\n"}]}