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