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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 16, 2014, 22:02 UTC
Message-ID: <xmqqppkhexw3.fsf@gitster.dls.corp.google.com>
In-Reply-To: <1397681938-18594-1-git-send-email-mcgrof@do-not-panic.com>

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

> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> Upstream Linux kernel commit c5905afb was introduced on v3.4 but
> git describe --contains yields v3.5

Actually, "describe --contains" should yield v3.5-rc1~120^3~76^2, not v3.5.

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.

And between v3.4 and v3.5-rc1, the latter is a closer anchor point for that commit (v3.5-rc1 only needs about 200 hops to reach the commit, while from v3.4 you would need close to 500 hops), hence we end up picking the latter as "a better answer".

Now, with the explanation of how/why this happens behind us, I see two possible issues with this patch:

 - The reason a human-user rejects v3.5-rc1~120^3~76^2 as the
   solution and favor v3.4~479^2~9^2 could be because of the -rc1
   part in the answer.  Perhaps we would want an option that affects
   which tags are to be used (and which tags are to be excluded) as
   anchoring points?

 - If we are truly interested in finding out the "earliest tag that
   contains the given commit", shouldn't we be ignoring the tagname
   and go with the tag with the oldest timestamp?  After all, there
   may be a fix merged to v7.0 first on April 1st, and then on a
   later date the same fix may be merged to the maintenance track to
   be tagged as v6.9.1 on May 5th, and in such a case, wouldn't you
   want to say that the fix first appeared on v7.0 on April 1st,
   instead of on May 5th?

Thanks.