Re: [PATCH] doc: ls-tree paths do not support wildcards

From: Jeff King <peff@peff.net>
Date: May 28, 2020, 23:16 UTC
Message-ID: <20200528231622.GB1267915@coredump.intra.peff.net>
In-Reply-To: <xmqq4krz3edq.fsf@gitster.c.googlers.com>

On Thu, May 28, 2020 at 03:04:33PM -0700, Junio C Hamano wrote:

Show 6 quoted lines

> The documentation does not say paths can be wildcards.  It allows a
> list of "patterns to match" and never says they are wildcards.
> 
> I think they take the traditional "leading paths" (i.e. by saying
> "git ls-tree HEAD t/", you can show all paths that are under t/,
> and is different from the "raw path" i.e. "git ls-tree HEAD t").

Hmm, that might be weird if we switch to the pathspec matching code, because we're sort-of recursive and sort-of not. E.g.:

  $ mkdir -p one/two/three
  $ echo content >one/two/three/file
  $ git init && git add . && git commit -m foo

  $ git ls-tree HEAD
  040000 tree 8f303030860565e9c51101f993e1db4feb2792a7	one

  $ git ls-tree -r HEAD
  100644 blob d95f3ad14dee633a758d2e331151e950dd13e4ed	one/two/three/file

  git ls-tree HEAD one
  040000 tree 8f303030860565e9c51101f993e1db4feb2792a7	one

  $ git ls-tree HEAD one/
  040000 tree c89b49675f4ccf1d03f7c95b5f072566ce0d7f83	one/two

So the pathspec match triggers one level of recursion, which is unlike a pathspec used with non-recursive diff:

  $ git diff-tree --root --abbrev HEAD
  6f4ed388a766b500bcf3bbd9877cc7213c76a959
  :000000 040000 0000000 8f30303 A	one
  
  $ git diff-tree --root --abbrev -r HEAD
  6f4ed388a766b500bcf3bbd9877cc7213c76a959
  :000000 100644 0000000 d95f3ad A	one/two/three/file
  
  $ git diff-tree --root --abbrev HEAD one
  6f4ed388a766b500bcf3bbd9877cc7213c76a959
  :000000 040000 0000000 8f30303 A	one
  
  $ git diff-tree --root --abbrev HEAD one/
  6f4ed388a766b500bcf3bbd9877cc7213c76a959
  :000000 040000 0000000 8f30303 A	one

I think we should be able to reuse the pathspec matching code, but we may not be able to reuse other tree-walking bits. Or maybe we can. It looks like we already use read_tree_recursive(), so I guess our custom show_tree() callback is able to handle that. But definitely something to watch out for during any transition.

-Peff