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