{"thread":{"id":"29061","subject":"Anyone have a commit hook for forbidding old branches from being merged in?","startedAt":"2011-12-01T15:34:06Z","lastAt":"2011-12-02T11:27:06Z","messageCount":4,"participants":["Ævar Arnfjörð Bjarmason","Thomas Rast","Neal Kreitzinger"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"180200","messageId":"CACBZZX4LyTaz=fU1vvgpeL904QFjJULCMVSP0uutcuxZT+-vWQ@mail.gmail.com","threadId":"29061","inReplyTo":null,"subject":"Anyone have a commit hook for forbidding old branches from being merged in?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2011-12-01T15:34:06Z","receivedAt":"2011-12-01T15:34:06Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"I work on a web application that due to underlying database schema\nchanges etc only even compiles and runs for a given 2 week moving\nwindow.\n\nThus if someone started a branch say 1 month ago, works on it one and\noff, and then merges it back into the mainline it becomes impossible\nto bisect that code if it has a problem. You either have to:\n\n * Revert the whole merge\n * Manually eyeball the code to see where the error might be\n * Brute-force manually bisect it by checking out only the files\n   altered in those commits instead of the commit at a given\n   data. Usually individual files are still compatible with the new\n   code.\n\nBut the whole reason this is a problem is because people don't rebase\ntheir branches before merging them in, unintentionally causing\nproblems.\n\nSo before I write a hook to do this, is there anything that implements\na hook that:\n\n * Checks if you're pushing a merge commit\n * If so, is that merge based off and old version of $MAINBRANCH\n * Is the base of that branch more than N days old?\n * If so reject the push\n"},{"id":"180202","messageId":"201112011650.51547.trast@student.ethz.ch","threadId":"29061","inReplyTo":"CACBZZX4LyTaz=fU1vvgpeL904QFjJULCMVSP0uutcuxZT+-vWQ@mail.gmail.com","subject":"Re: Anyone have a commit hook for forbidding old branches from being merged in?","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2011-12-01T15:50:51Z","receivedAt":"2011-12-01T15:50:51Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> \n> So before I write a hook to do this, is there anything that implements\n> a hook that:\n> \n>  * Checks if you're pushing a merge commit\n>  * If so, is that merge based off and old version of $MAINBRANCH\n\nI think it suffices to check whether any boundary commit in the\nupdated range is older than what you allow, e.g.\n\nwhile read old new rev; do\n    # omitted: check it's an update, i.e., neither old nor new is 0..0\n    git rev-list --boundary $old..$new |\n    sed -n 's/^-//p' |\n    xargs git rev-list --no-walk --before='cutoff limit' >bad\n    test -s bad || exit 1\ndone\n\n(Not tested much; in particular I'm not sure you can get away without\nlimiting the number of args to rev-list to 1.  A simple test seems to\nindicate so, however.)\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"180236","messageId":"4ED82BCA.5080909@gmail.com","threadId":"29061","inReplyTo":"CACBZZX4LyTaz=fU1vvgpeL904QFjJULCMVSP0uutcuxZT+-vWQ@mail.gmail.com","subject":"Re: Anyone have a commit hook for forbidding old branches from being merged in?","fromName":"Neal Kreitzinger","fromEmail":"nkreitzinger@gmail.com","sentAt":"2011-12-02T01:37:14Z","receivedAt":"2011-12-02T01:37:14Z","isPatch":false,"sender":{"key":"nkreitzinger@gmail.com","avatar":null},"body":"On 12/1/2011 9:34 AM, Ævar Arnfjörð Bjarmason wrote:\n> I work on a web application that due to underlying database schema\n> changes etc only even compiles and runs for a given 2 week moving\n> window.\n>\n> Thus if someone started a branch say 1 month ago, works on it one and\n> off, and then merges it back into the mainline it becomes impossible\n> to bisect that code if it has a problem. You either have to:\n>\n> * Revert the whole merge * Manually eyeball the code to see where\n> the error might be * Brute-force manually bisect it by checking out\n> only the files altered in those commits instead of the commit at a\n> given data. Usually individual files are still compatible with the\n> new code.\n>\n> But the whole reason this is a problem is because people don't rebase\n> their branches before merging them in, unintentionally causing\n> problems.\n>\n> So before I write a hook to do this, is there anything that\n> implements a hook that:\n>\n> * Checks if you're pushing a merge commit * If so, is that merge\n> based off and old version of $MAINBRANCH * Is the base of that\n> branch more than N days old? * If so reject the push\n\nIt sounds like you're saying that people should rebase before merging to \nmain.  That means their merge would be a fast-forward.  You could just \nreject anyone who has not done a current rebase.  Then you could use \nthis technique from the pre-rebase.sample hook to enforce up-to-date \nrebases:\n\nonly_in_main='git rev-list \"^$topic\" main'\nif test -z \"$only-in-main\"\nthen\n     exit 0\nelse\n     echo >&2 \"error: please rebase on main before merging to main.\"\n     exit 1\nfi\n\nv/r,\nneal\n"},{"id":"180242","messageId":"CACBZZX5+AC0ZxsdNMrEEq=h+1KWDxXhCxL2P7UBdM=cPTwS7vA@mail.gmail.com","threadId":"29061","inReplyTo":"4ED82BCA.5080909@gmail.com","subject":"Re: Anyone have a commit hook for forbidding old branches from being merged in?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2011-12-02T11:27:06Z","receivedAt":"2011-12-02T11:27:06Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Fri, Dec 2, 2011 at 02:37, Neal Kreitzinger <nkreitzinger@gmail.com> wrote:\n\n> It sounds like you're saying that people should rebase before merging to\n> main.  That means their merge would be a fast-forward.  You could just\n> reject anyone who has not done a current rebase.  Then you could use this\n> technique from the pre-rebase.sample hook to enforce up-to-date rebases:\n\nThat would be an overly invasive change to people's workflows. It's\nfine if you merge something in as long as the initial merge base isn't\nN days older than the current state of the mainline.\n"}]}