From: Junio C Hamano <gitster@pobox.com>
Date: Fri, 30 Nov 2007 01:06:29 GMT
Subject: Re: [PATCH v3] Allow update hooks to update refs on their own
Message-ID: <7vr6i8sfsa.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <35C5BEA0-0D6C-4D2E-85E7-1B78FB0BEADA@midwinter.com>

Steven Grimm <koreth@midwinter.com> writes:

> If any one of #1-5 wasn't true or was solvable in a different way,
> then #6 wouldn't be needed. For example, if git-svn kept its mapping
> of git revisions to svn revisions somewhere else it could leave the
> commit messages untouched, meaning the SHA1s wouldn't change.

That does sound like an unfortunate design problem with how git-svn
keeps track of the correlation between two systems.

But after thinking about this issue a bit more, I think I agree that
allowing to munge what was pushed inside update hook may make sense even
outside of git-svn context (iow, if this were an ugly workaround for
git-svn deficiency then I would be unhappy but I think there are valid
use cases).  "You push A, I inspect it and may rewrite it to A' but only
if A' is reasonable -- otherwise I reject your pushing of A" could be a
valid thing to do in other contexts.  A stupid example would be an update
hook that tries to cleanse what you pushed for whitespace breakage and
commit a cleaned-up result only if the result passes the testsuite.