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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 17, 2014, 17:05 UTC
Message-ID: <xmqq8ur3ga2y.fsf@gitster.dls.corp.google.com>
In-Reply-To: <mvm8ur42zn6.fsf@hawking.suse.de>

Andreas Schwab <schwab@suse.de> writes:

Show 8 quoted lines

> 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.