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@xxxxxxxx> 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
--
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