Re: [PATCH] ls-tree path restriction semantics fixes

JM> This patch fixes the git-ls-tree semantics to be less stupid, namely: JM> * ls of a 'tree' path should just return the SHA1 of the tree JM> * ls of a 'tree' path with a trailing '/' should work properly JM> * ls of two identical paths should have the same output as ls of JM> a single path. (I consider ls-tree's output to be a hash dictionary)

I haven't read your code yet, but...

JM> Old Results:

JM> $ git-ls-tree t JM> 040000 tree 4eeb3990955b8badc4c14712b89d8cd9fff02f15 t JM> 100644 blob 6882e23be568ccf14f3adb0c766139086f2ee952 t/Makefile JM> 100644 blob 2a94fdb0b83ab5fcbf1a2c6edaf36c2dbe765ec6 t/README JM> 100644 blob d920c6b3a3bfbb5994244a78d1ad99ce02748122 t/lib-read-tree-m-3way.sh JM> ...

I presume the counterpart to this one in your "New Results" example, which is spelled "git-ls-tree f" is a typo of "git-ls-tree t", but if that is the case I strongly disagree.

What you really want is something similar to '-d' flag to /bin/ls. You are interested in the directory itself not its contents and I think your gripe is that giving a path that matches a tree always descends into it (i.e. there is no way to do the equivalent of "/bin/ls -d t"). I agree that it is a problem, but changing "/bin/ls t" not to show the directory contents of "t" is not a solution.

JM> $ git-ls-tree t/ JM> (no output)

I agree with you that this is not what we want and we should behave the same way as "git-ls-tree t" would in this case.

JM> $ git-ls-tree t t JM> 040000 tree 4eeb3990955b8badc4c14712b89d8cd9fff02f15 t

I do not know what you wanted to say in this example. Your "Old" and "New" look the same to me.