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

["Luis R. Rodriguez" <mcgrof@do-not-panic.com>]

On Wed, Apr 16, 2014 at 3:02 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "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.

Yes, indeed thanks, sorry I should have been explicit.

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

That'd be swell :)

> 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),

Ah! Thanks for explaining this mysterious puzzle to me. I'm a bit
perplexed why still. Can I trouble you for a little elaboration here?
How could one view from a commit merged on v3.4 possibly yield more
commits to v3.4 than to v3.5 ? Is it because it starts counting on the
merge's parent (v3.3) ?

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

I'd take an rc release as a blessed point too so not sure, and come to
think of it I'm not a bit perplexed why the results for my change did
not yield an rc1 as well.

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

At least for Linux linux-3.X.y branches (one example linux-3.4.y) on
linux-stable has different commit IDs from patches cherry picked from
Linus' tree, and that patch just referneces the upstream commit from
Linus' tree on the commit log, but nothing more.

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

Sure, but I'd expect the folks maintaining v6.9.x would just refer to
the upstream commit ID from v7.0.

  Luis