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

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

quoted

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