# Anyone have a commit hook for forbidding old branches from being merged in? 4 messages from 2011-12-01 to 2011-12-02. Participants: Ævar Arnfjörð Bjarmason, Thomas Rast, Neal Kreitzinger. Thread: https://gitlist.dev/t/29061 ## Ævar Arnfjörð Bjarmason, 2011-12-01 15:34 Subject: Anyone have a commit hook for forbidding old branches from being merged in? Message-ID: URL: https://gitlist.dev/e/CACBZZX4LyTaz%3DfU1vvgpeL904QFjJULCMVSP0uutcuxZT%2B-vWQ%40mail.gmail.com ``` I work on a web application that due to underlying database schema changes etc only even compiles and runs for a given 2 week moving window. Thus if someone started a branch say 1 month ago, works on it one and off, and then merges it back into the mainline it becomes impossible to bisect that code if it has a problem. You either have to: * Revert the whole merge * Manually eyeball the code to see where the error might be * Brute-force manually bisect it by checking out only the files altered in those commits instead of the commit at a given data. Usually individual files are still compatible with the new code. But the whole reason this is a problem is because people don't rebase their branches before merging them in, unintentionally causing problems. So before I write a hook to do this, is there anything that implements a hook that: * Checks if you're pushing a merge commit * If so, is that merge based off and old version of $MAINBRANCH * Is the base of that branch more than N days old? * If so reject the push ``` ## Thomas Rast, 2011-12-01 15:50 Subject: Re: Anyone have a commit hook for forbidding old branches from being merged in? Message-ID: <201112011650.51547.trast@student.ethz.ch> URL: https://gitlist.dev/e/201112011650.51547.trast%40student.ethz.ch In-Reply-To: ``` Ævar Arnfjörð Bjarmason wrote: > > So before I write a hook to do this, is there anything that implements > a hook that: > > * Checks if you're pushing a merge commit > * If so, is that merge based off and old version of $MAINBRANCH I think it suffices to check whether any boundary commit in the updated range is older than what you allow, e.g. while read old new rev; do # omitted: check it's an update, i.e., neither old nor new is 0..0 git rev-list --boundary $old..$new | sed -n 's/^-//p' | xargs git rev-list --no-walk --before='cutoff limit' >bad test -s bad || exit 1 done (Not tested much; in particular I'm not sure you can get away without limiting the number of args to rev-list to 1. A simple test seems to indicate so, however.) -- Thomas Rast trast@{inf,student}.ethz.ch ``` ## Neal Kreitzinger, 2011-12-02 01:37 Subject: Re: Anyone have a commit hook for forbidding old branches from being merged in? Message-ID: <4ED82BCA.5080909@gmail.com> URL: https://gitlist.dev/e/4ED82BCA.5080909%40gmail.com In-Reply-To: ``` On 12/1/2011 9:34 AM, Ævar Arnfjörð Bjarmason wrote: > I work on a web application that due to underlying database schema > changes etc only even compiles and runs for a given 2 week moving > window. > > Thus if someone started a branch say 1 month ago, works on it one and > off, and then merges it back into the mainline it becomes impossible > to bisect that code if it has a problem. You either have to: > > * Revert the whole merge * Manually eyeball the code to see where > the error might be * Brute-force manually bisect it by checking out > only the files altered in those commits instead of the commit at a > given data. Usually individual files are still compatible with the > new code. > > But the whole reason this is a problem is because people don't rebase > their branches before merging them in, unintentionally causing > problems. > > So before I write a hook to do this, is there anything that > implements a hook that: > > * Checks if you're pushing a merge commit * If so, is that merge > based off and old version of $MAINBRANCH * Is the base of that > branch more than N days old? * If so reject the push It sounds like you're saying that people should rebase before merging to main. That means their merge would be a fast-forward. You could just reject anyone who has not done a current rebase. Then you could use this technique from the pre-rebase.sample hook to enforce up-to-date rebases: only_in_main='git rev-list "^$topic" main' if test -z "$only-in-main" then exit 0 else echo >&2 "error: please rebase on main before merging to main." exit 1 fi v/r, neal ``` ## Ævar Arnfjörð Bjarmason, 2011-12-02 11:27 Subject: Re: Anyone have a commit hook for forbidding old branches from being merged in? Message-ID: URL: https://gitlist.dev/e/CACBZZX5%2BAC0ZxsdNMrEEq%3Dh%2B1KWDxXhCxL2P7UBdM%3DcPTwS7vA%40mail.gmail.com In-Reply-To: <4ED82BCA.5080909@gmail.com> ``` On Fri, Dec 2, 2011 at 02:37, Neal Kreitzinger wrote: > It sounds like you're saying that people should rebase before merging to > main.  That means their merge would be a fast-forward.  You could just > reject anyone who has not done a current rebase.  Then you could use this > technique from the pre-rebase.sample hook to enforce up-to-date rebases: That would be an overly invasive change to people's workflows. It's fine if you merge something in as long as the initial merge base isn't N days older than the current state of the mainline. ```