Re: [PATCH 0/5] RFC: patterns for branch list

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 26, 2011, 16:55 UTC
Message-ID: <7vwre0dsdy.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4E5759B1.50705@drmicha.warpmail.net>

Michael J Gruber <git@drmicha.warpmail.net> writes:

Show 8 quoted lines

> Jeff King venit, vidit, dixit 25.08.2011 19:53:
>> On Thu, Aug 25, 2011 at 10:30:16AM +0200, Michael J Gruber wrote:
>> 
>>> Both "tag" and "branch" could activate list mode automatically on an invalid
>>> tag name rather than dieing:
>>>
>>> git tag v1.7.6\*
>>> Warning: tag 'v1.7.6*' not found.

If it is not found, the usual action is create it, no?

Show 13 quoted lines

>>> v1.7.6
>>> v1.7.6-rc0
>>> v1.7.6-rc1
>>> v1.7.6-rc2
>>> v1.7.6-rc3
>>> v1.7.6.1
>> 
>> That just seems confusing to me. What is the exit status? Shouldn't the
>> warning be "error: tag 'v1.7.6*' is not a valid tag name"?
>
> Sure, and sorry, copied the wrong one. I'd just like to have the simple
> way to say "git branch peff/\*" at least as long as we don't have "-l"
> for "--list".

As we use fnmatch() and not match_pathspec() for this pattern matching, "git branch peff/" will not list all the topics under the peff/ hierarchy (your example "git branch peff/\*" would be the way), but I would imagine that we may someday want to update it to allow the leading path match here. And at that point, distinction between

	git branch peff  ;# to create a "peff" branch
        git branch peff/ ;# to list "peff/" branches, as "peff/" itself is
        		 ;# an invalid branch name and your auto listing
                         ;# heuristic kicks in

while it might be very useful for experts, becomes too subtle and would confuse new people. We should instead require an explicit -l/--list, and not use the auto listing heuristics (it is fine for -v to imply -l).