From: Junio C Hamano Date: Mon, 28 Nov 2005 01:07:07 GMT Subject: Re: [PATCH 6/8] ls-tree: work from subdirectory. Message-ID: <7vveyd37ic.fsf@assigned-by-dhcp.cox.net> In-Reply-To: Linus Torvalds 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?