Re: [PATCH/RFC] branch: add optional parameter to -r to specify remote

[Jeff King <peff@peff.net>]

On Mon, Jun 20, 2011 at 01:08:13PM +0200, Michael J Gruber wrote:

> > For that matter, --match should be spelled "--glob", as we already have:
> > 
> >   $ git log --glob='jk/*'
> > 
> > I think having the ref-selection for "git branch" match that of the
> > revision walker makes sense.
> 
> Well, "branch" is about refs, and "log" about revs.

Sure, and I wouldn't expect "git branch --list 1234abcd" to do anything
useful. But naming refs is a subset of naming revs. Certainly it seems
worth it to make the shorthands like "--remotes" behave the same way
where applicable.

I do agree that "git branch -l 'jk/*'" is less typing than "--glob"; it
may be worth supporting both forms to provide the least surprise to the
user (i.e., even though it may not be the shortest, users may expect the
same syntax to work in both places, and it costs us very little to
accept either).

> I'd rather have
> "branch" similar to "tag" in that respect (i.e. '-l'). I'm still meaning
> to revive that series:
> 
> http://permalink.gmane.org/gmane.comp.version-control.git/172228

Modulo Junio's comments on the "-l" transition, I like the idea. One
thing jumped out at me:

> -       else if (argc == 0)
> -               return print_ref_list(kinds, detached, verbose, abbrev, with_commit);
> +       else if (argc == 0 || (verbose && argc == 1))
> +               return print_ref_list(kinds, detached, verbose, abbrev, with_commit, argc ?  argv[0] : NULL);

Is there any reason not to accept:

  git branch --list jk/* mg/*

? For "tag -l", we seem to silently ignore any arguments past the first:

  $ git tag -l 'v1.7.4.*' 'v1.7.5.*'
  v1.7.4.1
  v1.7.4.2
  v1.7.4.3
  v1.7.4.4
  v1.7.4.5

We should at least warn and say "your second argument is being ignored"
or show the usage message.  But perhaps it is even friendlier to accept
a list of patterns.

-Peff