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

[Junio C Hamano <junkio@cox.net>]

Linus Torvalds <torvalds@osdl.org> writes:

> On Sun, 27 Nov 2005, Petr Baudis wrote:
>> Ugh. That's really weird. Wouldn't a better approach be to fix
>> git-ls-files to behave more sanely? (That is, listing the entry for
>> drivers/char instead of drivers?)

It behaves sanely, just not in the way you are expecting.

> Well, it's not actually confusing if you see a path spec for
> what it is: it's not a filename, it's a _pattern_.

Well, that is confusing, although it may be sane.

> So you should always do
>
> 	git-ls-tree -r pattern
>
> (and yes, we could even hardcode "-r", because git-ls-tree without it 
> really is a pretty strange thing).

If you mean "in the presense of pathspec, default to -r", I
*might* agree, but I am not convinced yet.

Without pathspec, ls-tree is a pretty-printing version of
"git-cat-file tree", and that is how the command is used by the
git browsers like gitweb.  I have never looked at qgit source,
but I'd be surprised if it did not depend on the single-level
behaviour of ls-tree for that purpose.

It *is* "/bin/ls" after all, and you _would_ get annoyed if your
/bin/ls always recursed if you gave an argument.  Imagine going
to the kernel source and try "/bin/ls arch" with your version of
/bin/ls that always recurses, when you only wanted to get the
list of architectures you are supporting ;-).

> The _real_ strangeness in "git-ls-tree" is that it shows the tree nodes at 
> all, which no other git tool does when it recurses. 

Very true.  I do not think even git browsers need that but I may
be mistaken.

Having said all of the above, I do understand why we would
_also_ want the behaviour parallel to ls-files, not /bin/ls
behaviour.  Maybe we should have both?  Either rename the
current ls-tree to browse-tree, and make the one that parallels
ls-files the new ls-tree?