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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html