Re: [PATCH] tag: do not show ambiguous tag names as "tags/foo"

[Jeff King <peff@peff.net>]

On Sun, Jan 24, 2016 at 02:12:35AM -0500, Jeff King wrote:

> In theory, the ref-filter code could figure this out by us
> passing FILTER_REFS_TAGS. But there are two complications
> there:
> 
>   1. The handling of refname:short is deep in formatting
>      code that does not even have our ref_filter struct, let
>      alone the arguments to the filter_ref struct.
> 
>   2. In git v2.7.0, we expose the formatting language to the
>      user. If we follow this path, it will mean that
>      "%(refname:short)" behaves differently for "tag" versus
>      "for-each-ref" (including "for-each-ref refs/tags/"),
>      which can lead to confusion.
> 
> Instead, let's extend the "short" modifier in the formatting
> language to handle a specific prefix. This fixes "git tag",
> and lets users invoke the same behavior from their own
> custom formats (for "tag" or "for-each-ref") while leaving
> ":short" with its same consistent meaning in all places.

I think the patch I posted is a reasonable way to go. But I also don't
think that having "%(refname:short)" behave specially for "git-tag" is
all that unreasonable, either. But I'm open to argument.

Here are a few more considerations I had.

 - I'm not sure if the "special" behavior works as well for git-branch,
   which may want to shorten both "refs/heads/" and "refs/remotes/",
   depending on the type of ref.

   My solution may not extend there naturally, either, depending on how
   it is implemented.

 - To let users get the same behavior out of for-each-ref, we could
   perhaps auto-infer that looking at "refs/tags/" means shortening and
   disambiguation should only happen with respect to the "refs/tags/"
   hierarchy.

   But I'm uncomfortable changing the meaning of ":short" without at
   least a new option. And what would it mean for "git for-each-ref
   refs/heads/foo/"? Would it shorten "refs/heads/foo/bar" to just
   "bar", or would it still be "foo/bar"?

-Peff