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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]