From: Dun Peal <dunpealer@gmail.com>
Date: Fri, 08 Oct 2010 22:57:16 GMT
Subject: Re: Efficiently detecting paths that differ from each other only in case
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:
> 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