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

[Jeff King <peff@peff.net>]

On Thu, Aug 25, 2011 at 10:30:16AM +0200, Michael J Gruber wrote:

> This mini series is about introducing patterns to the list mode of
> 'git branch' much like the pattern for 'git tag -l'. There are several
> related things which are to be considered for the ui design:

> [log vs tag vs branch]

I agree that the ideal UI change would be to move git-branch's "-l" to
"-g", and make "-l|--list" work the same as it does for git-tag.

Even though branch is generally considered a porcelain, I worry a little
about making that change. A script that wants to create a branch has no
real choice other than to use "git branch" (OK, they can use
"update-ref" themselves, but I seriously doubt that most scripts do so).
However, I kind of doubt anyone actually uses "-l"; it is mostly
pointless in the default config, so maybe it is safe.

Searching google code for "git.branch.*-l" turns up only one hit, and it
is somebody who apparently thought that "-l" meant "list".

> Analogous to "git tag", "branch" has several modes, one of which is list mode.
> It is currently activated (and possibly modified) by "-v" and "-vv", and when
> there are no arguments. So, at the least,
> 
> git branch -v[v] <pattern>
> 
> should match just like "git tag -l <pattern>" does. And that is what the first
> patch in my series does.

The order of your patches seems backwards to me. You add
pattern-matching for "-v", but there is no way to get pattern-matching
for the non-verbose case. Shouldn't "--list" come first?

Maybe I am just nitpicking, as I think the end result after the series
is the same. I just found the first patch very confusing.

> "git tag" should probably learn the same long option and others. And why not
> verify tags given by a pattern?

Yeah, having them both do --list makes sense. Whether it is appropriate
to glob for other operations, I don't know. I think you'd have to
look at each operation individually.

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

> -v[v] sanity
> ============
> 
> '-v' and '-vv' both take considerable time (because they need to walk).
> It makes more sense to have '-v' display cheap output (upstream name)
> and '-vv' add expensive output (ahead/behind info). '-vvv' could add super
> expensive info (ahead/equivalent/behind a la cherry-mark).

I think the original rationale was not so much "how much time does it
take", but rather "how much space do you want each line to take on your
terminal". For many people, the upstream name in "-vv" is just
cluttering noise.

Tag and branch listing are really just specialized versions of
for-each-ref. I wonder if it makes sense to do:

  1. Teach for-each-ref formats replacement tokens for ahead/behind
     counts.

  2. Let the user specify a for-each-ref format for tag and branch
     listing output. Then the various levels of "-v" just become some
     special format strings, and the user is free to ask for whatever
     they want (or even have "branch.defaultListFormat" to get it
     without typing over and over).

-Peff