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

From: Linus Torvalds <torvalds@osdl.org>
Date: Nov 27, 2005, 18:01 UTC
Message-ID: <Pine.LNX.4.64.0511270949540.13959@g5.osdl.org>
In-Reply-To: <7vr792fnta.fsf@assigned-by-dhcp.cox.net>

On Sun, 27 Nov 2005, Junio C Hamano wrote:

> 
> True; that is more or less deliberate.  The behaviour is
> modelled after what "/bin/ls -a" does.

Yes, I did realize, and maybe it's fine. It's just that right now, git-ls-tree doesn't work like git-ls-files, which is kind of sad.

I suspect not a lot of people use git-ls-tree, and that's probably why it never was updated to match anything else.

It would be nice (I think) if git-ls-tree matched git-ls-files the same way git-diff-tree matches git-diff-files: exact same behaviour, except one works on a tree and another on the index. And like the git-diff-*, the index would always default to "-r", while for the tree version you would have to specify it.

(Yeah, there are differences. git-ls-files has the "--others" etc logic, but I think there are more similarities than differences).

Show 8 quoted lines

> However, this patch changes its behaviour in another way, and
> that could impact Porcelains more than the removal of the "-d"
> option.  Currently, "git-ls-tree <tree> $dir" shows what
> "/bin/ls -a -1 $dir" would show --- the tree for $dir itself and
> its immediate children.  This patch changes it to show the tree
> for $dir and nothing else.  In effect, "-d" becomes the default
> that you cannot turn off, except using "-r" to allow it go all
> the way down.

No, actually, it's even stranger than that.

If you use "-r", it acts the way you'd expect. If you _don't_ use "-r", it acts strangely, but very consistently with git-diff-tree: it only ever shows the _first_ part of a pathname. So

	git-ls-tree HEAD drivers/char/

should show just one entry: "drivers". While adding a "-r" should show all files under drivers (and the trees leading up to it).

And yes, you're right. That's a much bigger change by my suggested diff, and more likely to cause confusion.

			Linus