Re: [PATCH] ls-tree path restriction semantics fixes
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:41:58
quoted
quoted
quoted
quoted
"JM" == Jason McMullan [off-list ref] 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.