git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jeff King <peff@peff.net>
Date
Jan 24, 2016, 07:18 UTC
Message-ID
<20160124071815.GB24084@sigill.intra.peff.net>
In-Reply-To
<20160124071234.GA24084@sigill.intra.peff.net>
On Sun, Jan 24, 2016 at 02:12:35AM -0500, Jeff King wrote:
Show 19 quoted lines
> 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
Previous: Jeff KingNext: Junio C Hamano
Message 3 of 19 in “Regression? Ambiguous tags listed as "tags/<foo>"”
  1. Pete HarlanJan 23, 2016
  2. tag: do not show ambiguous tag names as "tags/foo"Jeff King, Jan 24, 2016
  3. Jeff KingJan 24, 2016
  4. Junio C HamanoJan 24, 2016
  5. Jeff KingJan 24, 2016
  6. Eric SunshineJan 24, 2016
  7. Jeff KingJan 25, 2016
  8. Junio C HamanoJan 25, 2016
  9. Jeff KingJan 25, 2016
  10. Karthik NayakJan 25, 2016
  11. Junio C HamanoJan 25, 2016
  12. Jeff KingJan 26, 2016
  13. Jeff KingJan 26, 2016
  14. Junio C HamanoJan 26, 2016
  15. Jeff KingJan 24, 2016
  16. 1/2 t6300: use test_atom for some un-modern testsJeff King, Jan 24, 2016
  17. 2/2 tag: do not show ambiguous tag names as "tags/foo"Jeff King, Jan 24, 2016
  18. Junio C HamanoJan 26, 2016
  19. Karthik NayakJan 26, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.