Dun Peal <dunpealer@xxxxxxxxx> writes: > On Fri, Oct 8, 2010 at 3:06 PM, Jeff King <peff@xxxxxxxx> wrote: > > Re-reading your original message, I have a few more thoughts. > > > > One is that you don't need to do this per-commit. You probably want to > > do it per-updated-ref, each of which may be pushing many commits. And > > then you either reject the new ref value or not. > > I think I do, actually, because let's say the developer pushes two > commits, 1<-2. Suppose commit 1 violates the rule, but commit 2 > reverts the violation. One might think that we don't care, since the > head will now be on 2, which is a correct state. But in fact we do, > because this is Git, and anyone may branch of from 1 in the future, > and voila we have a head in an incorrect state. Sidenote: why not detect violation earlier, by having pre-commit hook in each developer repository check for such violation? It is not as time sensitive on the local side (when creating a commit, you have to take some time to write commit message anyway). See how example pre-commit hook check for "non-ascii" file names. -- Jakub Narebski Poland ShadeHawk on #git -- 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