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

From: Andreas Schwab <schwab@suse.de>
Date: Apr 17, 2014, 17:30 UTC
Message-ID: <87zjjj50eq.fsf@igel.home>
In-Reply-To: <xmqq8ur3ga2y.fsf@gitster.dls.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 6 quoted lines

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

I've used --match only to force git describe to find a better match.

Show 8 quoted lines

> 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?"

IMHO git should select based on topology: the first tag that isn't contained in any other tag still containing the commit in question, only when ambigous it needs to fall back to other criteria.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."