On Wed, Apr 16, 2014 at 3:02 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > "Luis R. Rodriguez" <mcgrof@xxxxxxxxxxxxxxxx> writes: > >> From: "Luis R. Rodriguez" <mcgrof@xxxxxxxx> >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html