{"thread":{"id":"26078","subject":"disallowing non-trivial merges on integration branches","startedAt":"2010-12-15T18:27:16Z","lastAt":"2010-12-15T22:04:26Z","messageCount":2,"participants":["Adam Monsen","Vallon, Justin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"158191","messageId":"loom.20101215T185931-347@post.gmane.org","threadId":"26078","inReplyTo":null,"subject":"disallowing non-trivial merges on integration branches","fromName":"Adam Monsen","fromEmail":"haircut@gmail.com","sentAt":"2010-12-15T18:27:16Z","receivedAt":"2010-12-15T18:27:16Z","isPatch":false,"sender":{"key":"haircut@gmail.com","avatar":"https://avatars.githubusercontent.com/u/50639?v=4"},"body":"Does anyone have or want to help with a hook script to prevent trivial merges?\n\nHere's some context:\n\nI'm using the phrase \"trivial merge\" to refer to a merge without conflicts, \nlike, when two distinct files are edited.\n\nIn the Mifos project, the \"head\" repo at sf.net--for all intents and purposes--\nis the authoritative place to find Mifos source code. At my request, many of the \ndevs pushing to \"head\" have started using rebase more often than merge when \ntheir local copy of a branch diverges from the corresponding remote[1] (for \nexample, I commit to my \"master\", but must fetch then merge or rebase before \npushing to origin/master). Liberal use of rebase has really cleaned up our \nversion history graph... it's much easier to see what was pushed and when, and \nthe progression of patches. Trivial merges just don't add anything helpful to \nthe commit history graph, IMHO. Non-trivial merges are of course still allowed. \nRebasing commits extant in the \"head\" repo at sf.net is disallowed.\n\nI've been working on a hook script[2] to disallow trivial merges to further \nenforce our policy. Well, really I'm just working on the test suite[3], another \nguy (also named Adam, coincidentally) is working on the hook script.\n\nA blocking bug with the hook script (might be a design flaw) is that it prevents \nnon-trivial merges.\n\nWanna help fix it?\n\nI don't understand the hook script... is it doing something that makes sense?\n\nThis was my first time writing a test harness in Bash script. Kinda fun, \nactually. Git certainly lends well to scripting, and it feels intentional. Good \nstuff.\n\nReferences (links) from the above email:\n1. http://article.gmane.org/gmane.comp.finance.mifos.devel/9597\n2. http://stackoverflow.com/questions/4138285\n3. https://gist.github.com/737842\n"},{"id":"158196","messageId":"982E526FA742C94E9AC26DA766FD07090A337E@NYCMBX3.winmail.deshaw.com","threadId":"26078","inReplyTo":"loom.20101215T185931-347@post.gmane.org","subject":"RE: disallowing non-trivial merges on integration branches","fromName":"Vallon, Justin","fromEmail":"justin.vallon@deshaw.com","sentAt":"2010-12-15T22:04:26Z","receivedAt":"2010-12-15T22:04:26Z","isPatch":false,"sender":{"key":"justin.vallon@deshaw.com","avatar":null},"body":"My two cents:\n\n* Rebase is evil (grab your pitchforks!).\n\n* One thing that I have found is that if you fetch/merge --no-ff in the authoritative repo, then you actually end up with a better graph.  Why?  If you allow fast-forward to the contributor, then in the case of a trivial merge on the contributor branch, the contributor will have merged master *into* the contributor branch, making the contributor the left-parent, and the master the right-parent.  If you 'merge --no-ff', then you insure that in the merge on master, the left-parent is master, and the right-parent is your contributor.  Then, you should be able to follow left-parents to trace your mainline.  Not sure if that would help your gitk graph.\n\n* It sounds like you have a problem following the merges.  Maybe the grapher needs to be enhanced?\n\n-- \n-Justin\n\n\n-----Original Message-----\nFrom: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On Behalf Of Adam Monsen\nSent: Wednesday, December 15, 2010 1:27 PM\nTo: git@vger.kernel.org\nSubject: disallowing non-trivial merges on integration branches\n\nDoes anyone have or want to help with a hook script to prevent trivial merges?\n\nHere's some context:\n\nI'm using the phrase \"trivial merge\" to refer to a merge without conflicts, \nlike, when two distinct files are edited.\n\nIn the Mifos project, the \"head\" repo at sf.net--for all intents and purposes--\nis the authoritative place to find Mifos source code. At my request, many of the \ndevs pushing to \"head\" have started using rebase more often than merge when \ntheir local copy of a branch diverges from the corresponding remote[1] (for \nexample, I commit to my \"master\", but must fetch then merge or rebase before \npushing to origin/master). Liberal use of rebase has really cleaned up our \nversion history graph... it's much easier to see what was pushed and when, and \nthe progression of patches. Trivial merges just don't add anything helpful to \nthe commit history graph, IMHO. Non-trivial merges are of course still allowed. \nRebasing commits extant in the \"head\" repo at sf.net is disallowed.\n\nI've been working on a hook script[2] to disallow trivial merges to further \nenforce our policy. Well, really I'm just working on the test suite[3], another \nguy (also named Adam, coincidentally) is working on the hook script.\n\nA blocking bug with the hook script (might be a design flaw) is that it prevents \nnon-trivial merges.\n\nWanna help fix it?\n\nI don't understand the hook script... is it doing something that makes sense?\n\nThis was my first time writing a test harness in Bash script. Kinda fun, \nactually. Git certainly lends well to scripting, and it feels intentional. Good \nstuff.\n\nReferences (links) from the above email:\n1. http://article.gmane.org/gmane.comp.finance.mifos.devel/9597\n2. http://stackoverflow.com/questions/4138285\n3. https://gist.github.com/737842\n\n"}]}