Re: Efficiently detecting paths that differ from each other only in case

From: Dun Peal <dunpealer@gmail.com>
Date: Oct 8, 2010, 22:57 UTC
Message-ID: <AANLkTi=YQOVYsK6Brq5pMiAdrH3Un7RgrWvYf_pymT=d@mail.gmail.com>
In-Reply-To: <20101008200657.GA10954@sigill.intra.peff.net>

On Fri, Oct 8, 2010 at 3:06 PM, Jeff King <peff@peff.net> wrote:

Show 5 quoted lines

> 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