From: Junio C Hamano <junkio@cox.net>
Date: Sat, 28 May 2005 03:31:05 GMT
Subject: Re: [PATCH] ls-tree path restriction semantics fixes
Message-ID: <7v1x7syqkm.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <1117221986.11542.29.camel@jmcmullan.timesys>

>>>>> "JM" == Jason McMullan <jason.mcmullan@timesys.com> writes:

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

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

JM>   I don't see the problem there.

I do not see the problem either in Turing sense, but that is
like saying you could code anything given an assembler.  There
is a difference between being possible and being practical.

I do think the current behaviour is broken, so I think we are in
half agreement.  What I think is the cleanest would be to make
"git-ls-tree $tree" behave similarly to what "/bin/ls -a" does.
Then we have various combination of options, and also path
arguments, to think about.  How about doing something like this?

 - Running without any paths.

   "git-ls-tree $tree" shows everything first level, just like
   "/bin/ls -a" shows everything in cwd.  There is nothing to
   fix here.

 - Running with paths.

   "git-ls-tree $tree path1 path2..." should show path$n if
   path$n is not a tree and everything under path$n including
   path$n itself if path$n is a tree, just like the way "/bin/ls
   -a path1 path2..." works.  There is major breakage here as
   you pointed out with your "git-ls-tree $tree t" vs
   "git-ls-tree $tree t t" example.

 - Recursive behaviour without paths.

   "git-ls-tree -r $tree" should show everything recursively,
   just like what "/bin/ls -a -R" does.  There is nothing to
   fix.

 - Recursive behaviour with paths.

   "git-ls-tree -r $tree path1 path2..." should show everything
   recursively under path$n, just like what "/bin/ls -a -R path1
   path2..." does.  Again this is not how it currently works as
   you pointed out.

 - With paths but not descending into them.

   "git-ls-tree -d $tree path1 path2..." should show only the
   named path$n even when path$n is a tree, just like what
   "/bin/ls -a -R -d path1 path2..." does.  This is what is
   missing from today's git-ls-tree.