Re: ls-tree and wildcards

From: Junio C Hamano <gitster@pobox.com>
Date: May 15, 2012, 15:35 UTC
Message-ID: <7vd365foec.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CACsJy8AdoOcUxq+pmhAPxiPAiQc60aCLf7Jt31YFW4+6OHZEEg@mail.gmail.com>

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

Show 10 quoted lines

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