ls-tree and wildcards

ls-tree and wildcards

[Ryan McCue]

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,

-- 
Ryan McCue
<http://ryanmccue.info/>

Re: ls-tree and wildcards

[Nguyen Thai Ngoc Duy]

On Sat, May 12, 2012 at 10:07 PM, Ryan McCue <lists@rotorised.com> wrote:
> 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.

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?
-- 
Duy

Re: ls-tree and wildcards

[Ryan McCue]

Nguyen Thai Ngoc Duy wrote:
> I don't think it ever does. There's a mention of "patterns" in ls-tree
> man page, which is misleading.

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

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

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
<http://ryanmccue.info/>

Re: ls-tree and wildcards

[Junio C Hamano]

Ryan McCue <lists@rotorised.com> writes:

> 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,...

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.

Re: ls-tree and wildcards

[Nguyen Thai Ngoc Duy]

On Mon, May 14, 2012 at 11:43 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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.

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.
-- 
Duy

Re: ls-tree and wildcards

[Junio C Hamano]

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

> On Mon, May 14, 2012 at 11:43 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> 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.
>
> 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.

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.