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

On Wed, Apr 16, 2014 at 3:02 PM, Junio C Hamano [off-list ref] wrote:

"Luis R. Rodriguez" [off-list ref] writes:

quoted

From: "Luis R. Rodriguez" <redacted>

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