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

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

"Luis R. Rodriguez" <mcgrof@do-not-panic.com> writes:

> I think ultimately this reveals that given that tags *can* be
> arbitrary and subjective,...

Yes; see the part at the bottom.

>> Commit A can be described in terms of both v3.4 and v9.0,
>
> And in the real example case, why *would* c5905afb' be be described in
> terms of v3.5 instead of v3.4 ?

I am not interested in graphing that particular history between v3.4
and v3.5 myself.  If you are interested, I already gave you enough
information on how to figure that out.

>>     - find candidate tags that can be used to "describe --contains"
>>       the commit A, yielding v3.4, v3.5 (not shown), and v9.0;
>
>>     - among the candidate tags, cull the ones that contain another
>>       candidate tag, rejecting v3.5 (not shown) and v9.0;
>
>>     - among the surviving tags, pick the closest.
>>
>> Hmm?
>
> Sounds good to me!

Not so fast ;-)

My other message to Peff in response to his another example has an
updated position on this.  "Reject candidates that can reach other
candidates" is universally correct, but after that point, there are
at least three but probably more options that suit preference of
different people and project to break ties:

 - Your case that started this thread may want to favor v3.4 if only
   because that v3.4 _sounds_ smaller than v4.0 (in Peff's example),
   even when v3.4 and v4.0 do not have ancestry relationship.

 - The "closest" we have had is a heuristic to produce a result that
   is textually shorter.

 - And as I alluded to, "which one has the earliest timestamp?", is
   another valid question to ask.

And there may be more to appear.  A new command line option (and
possibly a new configuration) to choose from these three (and more
heuristics that will be added later) would be necessary.