Re: [PATCH] tag: add -i and --introduced modifier for --contains
- From
- Luis R. Rodriguez <mcgrof@do-not-panic.com>
- Date
- Apr 16, 2014, 22:35 UTC
- Message-ID
- <CAB=NE6VvDrMQ4ybF10MpXM-2672OdUTC_Rp2mdO3a5fuo1-H1Q@mail.gmail.com>
- In-Reply-To
- <xmqqppkhexw3.fsf@gitster.dls.corp.google.com>
On Wed, Apr 16, 2014 at 3:02 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 9 quoted lines
> "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) ?
Show 11 quoted lines
> 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.
Show 6 quoted lines
> - 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