Anyone have a commit hook for forbidding old branches from being merged in?

Anyone have a commit hook for forbidding old branches from being merged in?

[Ævar Arnfjörð Bjarmason]

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

Re: Anyone have a commit hook for forbidding old branches from being merged in?

[Thomas Rast]

Æ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

Re: Anyone have a commit hook for forbidding old branches from being merged in?

[Neal Kreitzinger]

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

Re: Anyone have a commit hook for forbidding old branches from being merged in?

[Ævar Arnfjörð Bjarmason]

On Fri, Dec 2, 2011 at 02:37, Neal Kreitzinger <nkreitzinger@gmail.com> 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.