Steven Grimm <koreth@xxxxxxxxxxxxx> 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. - 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
