"Luis R. Rodriguez" <mcg...@do-not-panic.com> writes: > From: "Luis R. Rodriguez" <mcg...@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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
