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
Junio C Hamano <gitster@pobox.com>
Date
Jan 25, 2016, 20:21 UTC
Message-ID
<xmqqmvrtfm0u.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<20160125100141.GC24452@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I'm not sure "remove-standard-prefix" doesn't open its own questions.
> Like "what are the standard prefixes?".

It is easy to define, no? This is invented for the internal use of the listing modes of "tag" and "branch", so the users are welcome to use it if they see fit, but how the prefixes are stripped is defined by the convenience of these commands--the behaviour might even change when these commands are enhanced.

Show 13 quoted lines
> If we are going to go with "remove a prefix", I really don't think
> "remove if present" is too complicated a set of semantics (as opposed to
> "error out" you mentioned above).
>
> I do like "strip=<n>" for its simplicity (it's easy to explain), and the
> fact that it will probably handle the git-branch case for us. The only
> open question is what to do if there are fewer components, but I really
> think any of the 4 behaviors I gave earlier would be fine.
>
> Eric' globbing suggestion is simpler for the error case (as a prefix, it
> can be "remove if present"), but I think introducing globbing in general
> opens up too many corner cases (e.g., does "*" match "/", is "**"
> supported, etc).

Yeah, I really do not like any of the "do not error out but assume that the user would not care about the ambiguities" solutions for something we primarily intend to use for internal purposes.

I agree that "strip=<n>", "remove-prefix=<glob>", and the friends are good for end-user scripting, but they can come later, outside of the scope of this regression fix, and that is the proper time to debate and decide if it is really ok to assume that the user does not care about ambiguity, or it is prudent to error out. A separate "remove-standard-prefix" that is meant for internal use would allow us to push the fix out without having to decide now.

Previous: Karthik NayakNext: Jeff King
Message 11 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.