Re: [PATCH 6/8] ls-tree: work from subdirectory.

Linus Torvalds [off-list ref] writes:

You're right, we need to keep the "-r" behaviour. 
If you take my last patch and make "ls_flags" default to 0 again, it 
should work correctly.

Maybe making "-r" the default and resurrecting "-d" to turn it
off would be the approach of least impact (-r becomes a
noiseword), if we take this "ls-tree should parallel ls-files"
idea.

The merge-recursive strategy uses ls-tree without -r with path
specifier to grab the sha1/mode of the three trees involved.
git-cvsexportcommit has the same assumption on how ls-tree
works.  It extracts a single SHA1 for the blob from the commit
object by "ls-tree $commit $blob_path".

With your two patches, they need to do this with "-r".

git-checkout and git-reset use -r to grab the whole tree, so
they are fine either way.  git-svnimport uses -r to read from a
tree (potentially a subtree) all the way down, so this one is
also fine.

So it probably is safer to default ls_options to LS_RECURSIVE,
and use "-d" to restrict it not to recurse.

But after seeing some more examples, I tend to think the current
one that models after how "/bin/ls -a" works in a way that is a
lot easier to understand.  For example, with your two patches
(defaulting to recursive)

	git-ls-tree HEAD

shows everything from the tree.  In order to get prettyprint of
HEAD tree (i.e. single level listing):

	git-ls-tree -d HEAD

is needed.  But there is no way to get the single level with
pathspec with these patches, so:

	cd Documentation && git-ls-tree -d HEAD

would not show the single level of Documentation tree, but just
a single line "tree" object of Documentation tree.  Which means
the way it works from the top and the way it works in a
subdirectory is quite different.

I'll throw in your two patches to the proposed updates branch so
that Porcelain/Browser people can play with it and decide.  I
really love the decrease of number of lines of code, but I am
afraid this would end up breaking things without real merit.