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. > Also, you could try not looking at the whole tree by [...] > only be manually expanding each level [...] > But that means many git ls-tree calls. Yeah, that's a pretty good idea, if not for the many ls-tree calls. With their overhead, I strongly suspect it may be slower than the solution you seem to propose, which is: git ls-tree -r <commit> which should give the full list of all paths in a commit, upon which I can decide to accept or reject. Thanks, D -- 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