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

[Jeff King <peff@peff.net>]

On Fri, Oct 08, 2010 at 02:57:49PM -0500, Dun Peal wrote:

> On Fri, Oct 8, 2010 at 2:51 PM, Jeff King <peff@peff.net> wrote:
> > One thing to consider, though, is if this is a hook running on the
> > server, you probably don't want to look at the index. You probably want
> > to look for duplicates in one tree entry (fed to the hook). So you would
> > be using git ls-tree, which probably is a bit slower.
> 
> Thanks, but why is that?  Why can't I use ls-files, and must use use
> ls-tree, which you say would be slower?

For two reasons:

  1. Bare repos generally don't _have_ an index, as it is about
     maintaining the state of the working tree.

  2. Even if you did have an index, it would presumably represent the
     contents of HEAD. But if you are feeding a commit to a hook, then
     that hook will get some sha1 of the to-be-pushed commit. So you
     need to look at the paths that are in that hook.

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.

Also, you could try not looking at the whole tree by doing something
like:

  git diff-tree --diff-filter=A --name-only $old $new

and then only considering duplicates for newly introduced files. But
that means for each introduced file, you need to enumerate the tree to
find case-sensitive matches. You can avoid looking at the whole tree
only be manually expanding each level (e.g., you see that foo/bar is
new. So you look at the root tree, looking for "foo" or case-insensitive
equivalents. For each one you find, you look further down for "bar" or a
case-insensitive equivalent). But that means many git ls-tree calls. So
I don't think it buys you anything in practice.

-Peff