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
Karthik Nayak <karthik.188@gmail.com>
Date
Jan 25, 2016, 19:29 UTC
Message-ID
<CAOLa=ZQmX6QMTz+dki+q07F+pHjUETLRdjJR5=nw8meYfoyEeQ@mail.gmail.com>
In-Reply-To
<20160125100141.GC24452@sigill.intra.peff.net>
On Mon, Jan 25, 2016 at 3:31 PM, Jeff King <peff@peff.net> wrote:
Show 32 quoted lines
> On Sun, Jan 24, 2016 at 06:26:50PM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>> > Yeah, "strip=2" would also get the job done, and extends more naturally
>> > to the branch case.
>> >
>> > To be honest, I cannot imagine anybody using anything _but_ strip=2...
>>
>> I 100% agree, and I do consider this to be internal implementation
>> detail for the listing modes of "tag" (and "branch"), which may be
>> exposed to the user (by documenting that %(refname:X) is used by
>> default), so perhaps even the flexibility of strip=2 is unwanted.
>>
>> I know what "remove-standard-prefix" is way too long for the value
>> of X above, but then we can say "the command will error out if you
>> allow your for-each-ref invocation to step outside of the area that
>> has standard prefix to be removed." without having to worry about
>> "what is the sensible thing to do when the prefixes are not what we
>> expect (too short for strip=2 or no match for short=refs/tags/)".
>
> I'm not sure "remove-standard-prefix" doesn't open its own questions.
> Like "what are the standard prefixes?".
>
> 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.

This seems ideal, it's also quite useful like your mentioned example. And would provide common ground for the upcoming git-branch patches as you said.

What about a scenario wherein we have refs/branches/abc/foo refs/branches/xyz

should --format="%(refname:strip=3)" give us
    foo
    xyz (here stripping till 2 '/', which is the maximum)
or
    foo
    refs/branches/xyz (no stripping done at all)

I prefer the former, cause that would allow us to give a maximum value for stripping and have everything below that maximum value stripped as well.

-- 
Regards,
Karthik Nayak
Previous: Jeff KingNext: Junio C Hamano
Message 10 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.