Re: [PATCH] tree_entry_interesting: Only recurse when the pathspec is a leading path component

Björn Steinbrink [off-list ref] writes:

On 2009.04.01 21:32:05 -0700, Junio C Hamano wrote:

quoted

I'm planning to queue this.
[Improved version of my patch]

Ah, thanks. Got busy with other stuff, and tried to fix another related
bug in ls-tree which made me forget to send the match_tree_entry fix :-/

That other ls-tree bug is with recursing into subdirectories, because
match_tree_entry matches even when the base is a subdirectory, but
ls-tree doesn't actually want that behaviour, I think. For example:

$ git ls-tree --abbrev HEAD git-gui/macosx/AppMain.tcl
100644 blob ddbe633	git-gui/macosx/AppMain.tcl

$ git ls-tree --abbrev HEAD  git-gui/
100644 blob f96112d	git-gui/.gitattributes
100644 blob 6483b21	git-gui/.gitignore
100755 blob b3f937e	git-gui/GIT-VERSION-GEN
100644 blob 3ad8a21	git-gui/Makefile
100755 blob 12e117e	git-gui/git-gui--askpass
100755 blob e018e07	git-gui/git-gui.sh
040000 tree f723285	git-gui/lib
040000 tree 73f3c34	git-gui/macosx
040000 tree 11cd1a0	git-gui/po
040000 tree 144728d	git-gui/windows

$ git ls-tree --abbrev HEAD git-gui/macosx/AppMain.tcl git-gui/
100644 blob f96112d	git-gui/.gitattributes
100644 blob 6483b21	git-gui/.gitignore
100755 blob b3f937e	git-gui/GIT-VERSION-GEN
100644 blob 3ad8a21	git-gui/Makefile
100755 blob 12e117e	git-gui/git-gui--askpass
100755 blob e018e07	git-gui/git-gui.sh
040000 tree f723285	git-gui/lib
100644 blob ddbe633	git-gui/macosx/AppMain.tcl
100644 blob b3bf15f	git-gui/macosx/Info.plist
100644 blob 77d88a7	git-gui/macosx/git-gui.icns
040000 tree 11cd1a0	git-gui/po
040000 tree 144728d	git-gui/windows

The last ls-tree shows all entries from git-gui/macosx/, beacuse the
first pattern makes it descend into that tree and all entries are
matched by the git-gui/ prefix. So the combined ls-tree shows more than
what the individual calls show. Seems wrong to me, but I'm unsure how to
tackle that, assuming that match_tree_entry is right in allowing any
base that's a subdirectory of a specified pathspec.

What might be confusing is how ls-tree, when run without an explicit
option -r (ecurse), comes up with candidates to show.  With pathspecs, you
are instructing it to recurse into subtrees as deep as needed to discover
all the paths that can match them, and your first pathspec causes the
contents of macosx subtree to be looked at for this reason.

Pathspecs are always OR'ed together, never AND'ed, and your second
pathspec git-gui covers them, so I do not think it is a bug.

If we had a glob support in the "leading path components" pathspec matcher
used by ls-tree/diff-tree, I would imagine you could do something like;

	ls-tree --recurse-to='*/*/*' $other $pathspec

to say "recurse three levels, but do not use */*/* as a filter to decide
what to show; the filters are only $other and $pathspec", iow, using

	(AND "*/*/*" (OR $other $pathspec))

semantics.  But I think this kind of complexity falls out of the "useful"
category and into a "mental exercise" category.