On Tue, Jan 26, 2016 at 5:34 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Jeff King <peff@xxxxxxxx> writes:
>
>> Since b7cc53e9 (tag.c: use 'ref-filter' APIs, 2015-07-11),
>> git-tag has started showing tags with ambiguous names (i.e.,
>> when both "heads/foo" and "tags/foo" exists) as "tags/foo"
>> instead of just "foo". This is both:
>>
>> - pointless; the output of "git tag" includes only
>> refs/tags, so we know that "foo" means the one in
>> "refs/tags".
>>
>> and
>>
>> - ambiguous; in the original output, we know that the line
>> "foo" means that "refs/tags/foo" exists. In the new
>> output, it is unclear whether we mean "refs/tags/foo" or
>> "refs/tags/tags/foo".
>>
>> The reason this happens is that commit b7cc53e9 switched
>> git-tag to use ref-filter's "%(refname:short)" output
>> formatting, which was adapted from for-each-ref.
>> ...
>
> Karthik, getting a fix in for "git tag" regression is more important
> than the topics parked in 'pu', so I'll queue this patch in the
> early part of 'pu'.
>
> I personally feel that "refname:strip=<n>" would be a good mechanism
> for end users to specify a custom format, and it is unclear to me
> what should happen when there are not enough elements to be
> stripped, so I do not think we want to cast the "we will show the
> whole thing" decision in stone prematurely only because we want to
> push out the regression fix soon. So I may ask Jeff to rework this
> one (or I may end up trying to do so myself) not to squat on the
> nice strip=<n> notation. refname:strip-standard-prefix that removes
> the known prefix ("refs/heads", "refs/remotes" and "refs/tags") if
> present and does not touch the refname otherwise would leave us more
> time to decide what strip=<n> should do in the error case.
>
> Unfortunately, this means kn/ref-filter-atom-parsing topic from you
> that were parked on 'pu' must be ejected for now, as any change in
> this area overlaps with it, and the atom parsing code would need to
> be updated to learn about the new attribute of the 'refname' atom
> (be it 'remove-prefix=<glob>', 'strip=<n>', or something else) that
> we would decide to use for the regression fix anyway.
That should be fine, there are still changes to be done there so I'll rebase
on this and send that series.
--
Regards,
Karthik Nayak
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html