Re: [PATCH] tag: add -i and --introduced modifier for --contains

[Junio C Hamano <gitster@pobox.com>]

Andreas Schwab <schwab@suse.de> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> And you are right that the commit is contained in v3.4, so we also
>> should be able to describe it as v3.4~479^2~9^2 as well.
>
> IMHO it should be described as v3.4-rc1~192^2~9^2, which is what git
> describe --contains --match=v3.4\* returns.  This path is only a few
> commits longer than v3.5-rc1~120^3~76^2.

Sure. In my response to Luis, I assumed that rc tags are not as
desirable as the final release points for his purpose for whatever
reason, as Luis compared between v3.4 and v3.5-rc1~120^3~76^2, not
with v3.4-rc1 or any later rc.

I also think this illustrates my earlier point. Depending on the
project and the expectation of the users, which tags are good
candidates as anchor points differ.  Your example using --match
probably shows a good direction to go in---somehow tell Git which
tags to base the description on, to reject names that the users do
not want.

When your project does not mind basing the description on rc tags,
between v3.4-rc1~192^2~9^2 and v3.5-rc1~120^3~76^2, I am not sure if
we would want to say that "the former is not so longer than the
latter, so use that", or what kind of heuristics to employ to reach
that conclusion.  Date-based selection (i.e. earliest first) is one
possibility.  Tagname-based selection has the issue of having to
configure "whose version numbering convention would you use when
sorting tags, and how you would tell Git that sorting order rule?"

For a possible cleaner alternative semantics, see the other message
I just sent to the thread.

Thanks.