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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html