On Wed, Mar 21, 2012 at 04:14:21PM -0500, Neal Kreitzinger wrote:
> >When I wrote my response, I assumed the intent was that people
> >_should_ be using --no-ff, but that he wanted to enforce it via hook
> >during a push to a central repository.
> >
> Would your script only work at "push time", or would it also work at
> "commit time"? I'm not sure at what point he thinks he wants to
> enforce it. I don't think git yet knows the info your script is
> asking for at "commit time" (ie, pre-commit hook and its brethren),
> and by the time it does know it's too late to block the commit
> locally. Maybe it does know that inof at the point one of those
> "commit time" hooks runs. I haven't tried it.
Completely untested, but you could probably do something like this in a
pre-commit hook:
if test "`git symbolic-ref HEAD 2>/dev/null`" = "refs/heads/master" &&
! test -e "`git rev-parse --git-dir`/MERGE_HEAD"
then
echo >&2 "Don't commit right on master. Go make a topic branch."
exit 1
fi
but I'm not sure if that would catch fast-forward merges or not. You
might also have to do an ancestry check against MERGE_HEAD.
Whether such a thing would be useful depends on your workflow and
exactly what you're trying to achieve. Usually people try to enforce
policy like this on pushes, just because that is an easy central point
(e.g., somebody who forgets to use topic branches or --no-ff may also
forget to set up their hooks; but if you have a central publishing
point, it's easy to set up the policies there just once).
-Peff
--
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