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

From: Jason McMullan <jason.mcmullan@timesys.com>
Date: 2005-05-28 05:26:25
On Fri, 2005-05-27 at 11:16 -0700, Junio C Hamano wrote:
> 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.


> 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


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Received on Sat May 28 05:26:39 2005

This archive was generated by hypermail 2.1.8 : 2005-05-28 05:26:39 EST