ls-tree and wildcards

Good evening folks,

I'm attempting to grab relevant information for files in a tree matching a given pattern with wildcards. The help for ls-tree indicates that it can accept a pattern of files to match, however I'm not able to see that.

$ git ls-tree origin/master ... 100644 blob 8c391e8fb44a38e1389a710ebf8af79612e592a6 screenshot-1.png 100644 blob ecb7159c1c02567e9cd5da83c254c538d331f733 screenshot-2.png 100644 blob f58eea7e27f98c01038262b823aa73ccd64cb01e screenshot-3.png 100644 blob 07e64def408145660cee657a46947077374762cc screenshot-4.png $ git ls-tree origin/master screenshot* $

(I've also tried quoting to ensure it's not bash playing up)

Is there some issue with the command I'm issuing? The documentation seems to indicate that I should be getting back the files which match the pattern.

Thanks,

On Sat, May 12, 2012 at 10:07 PM, Ryan McCue <lists@rotorised.com> wrote:

I don't think it ever does. There's a mention of "patterns" in ls-tree man page, which is misleading. We have the facilities to do that now ("lstree -r patterns" actually) but that might break backward compatibility. For now I guess you can just do

GIT_INDEX_FILE=/tmp/some-temporary-index git read-tree origin/master GIT_INDEX_FILE=/tmp/some-temporary-index ls-files <patterns>

A question that might help us understand your use case and give a better advice, or improve the system: why do you need that?

Nguyen Thai Ngoc Duy wrote:

Aha, I thought this might be the case. Thanks, I'll grep ls-tree then.

I need to be able to get all files starting with a certain string ("screenshot-" in this case) with certain extensions ("png", "jpg", "jpeg" or "gif" in this case). Passing into grep will do the trick, but a single command is my preferred option if it exists.

I don't mind this not existing in git (given that piping into grep will work just as well), but reading "patterns" on the man page made me think it may exist. I think the wording of that should probably be changed to avoid confusion.

Thanks for the response.

Ryan McCue <lists@rotorised.com> writes:

There are two uses of "pattern" there, and the former is probably OK but the latter is indeed misleading. Back when we wrote this command, there were two distinct "pathspec" families, and ls-tree belong to the one with "diff" family that did *not* take anything but "leading path pattern" (the other one from "ls-files" and "grep" family allowed wildcards). Giving a wildcard to the command in the "ls-tree/diff" family was never supported.

Later Nguyen and others started working on unifying the two separate "pathspec" semantics and we are probably halfway there. Many of the commands from "diff/log" family now can take wildcard (there may be new bugs in the codepaths, though), but "ls-tree" has not been converted.

On Mon, May 14, 2012 at 11:43 PM, Junio C Hamano <gitster@pobox.com> wrote:

Do we break backward compatibility by teaching ls-tree new pathspec semantics? I guess directories with wildcards in the name are rare, the chance of someone doing "ls-tree a*" is low. But I may miss something.

Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:

If you change ls-tree to use its paths arguments as pathspec, you will break backward compatibility.

But nobody stops us from _adding_ an option to ls-tree to tell it to switch between the two, i.e.

	git ls-tree HEAD -- '*.c'
	git ls-tree --pathspec HEAD -- '*.c'

The former will use the traditional "leading path match only" while the latter uses the (to-be) unified "pathspec" semantics.

Internally, the implementation could very well do something like this after parsing the options:

	if (!opt_pathspec)
        	prefix ":(noglob)" to all paths args

and use the updated code with magic pathspec support to handle both cases.