Re: [PATCH v3] Allow update hooks to update refs on their own

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 30, 2007, 01:06 UTC
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.