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

From: Jason McMullan <jason.mcmullan@timesys.com>
Date: May 27, 2005, 19:26 UTC
Message-ID: <1117221986.11542.29.camel@jmcmullan.timesys>
In-Reply-To: <7vmzqgzg8a.fsf@assigned-by-dhcp.cox.net>

On Fri, 2005-05-27 at 11:16 -0700, Junio C Hamano wrote:

Show 7 quoted lines

> 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.

  git-ls-tree reporting just the tree's hash is valid, because if
you want everything in that tree, you can just do:

git-ls-tree `git-ls-tree HEAD path/dir | (read m t h n; echo $h)`

  I don't see the problem there.

Show 5 quoted lines

> 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.

The problem was that 't' and 't t' produced *vastly* different output in the old code. 't' would emit everything in the tree, and 't t' would only emit t's hash.

-- 
Jason McMullan <jason.mcmullan@timesys.com>
TimeSys Corporation