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

2014-04-22 Thread Jan Kara
On Thu 17-04-14 10:04:52, Junio C Hamano wrote: So perhaps the rule should be updated to do something like: - find candidate tags that can be used to describe --contains the commit A, yielding v3.4, v3.5 (not shown), and v9.0; - among the candidate tags, cull the ones that

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

2014-04-22 Thread Junio C Hamano
Jan Kara j...@suse.cz writes: On Thu 17-04-14 10:04:52, Junio C Hamano wrote: So perhaps the rule should be updated to do something like: - find candidate tags that can be used to describe --contains the commit A, yielding v3.4, v3.5 (not shown), and v9.0; - among the

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

2014-04-21 Thread Luis R. Rodriguez
On Fri, Apr 18, 2014 at 4:36 PM, Junio C Hamano gits...@pobox.com wrote: Luis R. Rodriguez mcg...@do-not-panic.com writes: I think ultimately this reveals that given that tags *can* be arbitrary and subjective,... Yes; see the part at the bottom. Commit A can be described in terms of both

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

2014-04-21 Thread W. Trevor King
On Mon, Apr 21, 2014 at 05:38:34PM -0700, Luis R. Rodriguez wrote: [0] mcgrof@ergon ~/linux (git::master)$ git log c5905afb..v3.5| grep ^commit | wc -l 24878 [1] mcgrof@ergon ~/linux (git::master)$ git log c5905afb..v3.4| grep ^commit | wc -l 13106 [2] mcgrof@ergon ~/linux (git::master)$

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

2014-04-18 Thread Junio C Hamano
Jeff King p...@peff.net writes: ---A---B---C-D---E---F (maint, v3.4) \ \ / \ ---G-H---I (master, v4.0) \ / / --J--- The fix is J, and it got merged up to maint at D, and to master at H. v4.0 does not contain v3.4. What's the best

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

2014-04-18 Thread Luis R. Rodriguez
On Thu, Apr 17, 2014 at 10:04 AM, Junio C Hamano gits...@pobox.com wrote: Luis R. Rodriguez mcg...@do-not-panic.com writes: 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

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

2014-04-18 Thread Junio C Hamano
Luis R. Rodriguez mcg...@do-not-panic.com writes: I think ultimately this reveals that given that tags *can* be arbitrary and subjective,... Yes; see the part at the bottom. Commit A can be described in terms of both v3.4 and v9.0, And in the real example case, why *would* c5905afb' be be

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

2014-04-17 Thread Andreas Schwab
Junio C Hamano gits...@pobox.com writes: 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. IMHO it should be described as v3.4-rc1~192^2~9^2, which is what git describe --contains --match=v3.4\* returns. This path is

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

2014-04-17 Thread Junio C Hamano
Luis R. Rodriguez mcg...@do-not-panic.com writes: 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

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

2014-04-17 Thread Junio C Hamano
Andreas Schwab sch...@suse.de writes: Junio C Hamano gits...@pobox.com writes: 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. IMHO it should be described as v3.4-rc1~192^2~9^2, which is what git describe

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

2014-04-17 Thread Andreas Schwab
Junio C Hamano gits...@pobox.com writes: I also think this illustrates my earlier point. Depending on the project and the expectation of the users, which tags are good candidates as anchor points differ. Your example using --match probably shows a good direction to go in---somehow tell Git

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

2014-04-17 Thread Junio C Hamano
Andreas Schwab sch...@suse.de writes: Junio C Hamano gits...@pobox.com writes: ... When your project does not mind basing the description on rc tags, between v3.4-rc1~192^2~9^2 and v3.5-rc1~120^3~76^2, I am not sure if we would want to say that the former is not so longer than the latter,

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

2014-04-17 Thread Jeff King
On Thu, Apr 17, 2014 at 10:04:52AM -0700, Junio C Hamano wrote: Commit A can be described in terms of both v3.4 and v9.0, and it may be closer to v9.0 than v3.4, and under that definition we pick the closest tag, the current describe --contains behaviour may be correct, but from the human

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

2014-04-16 Thread Luis R. Rodriguez
From: Luis R. Rodriguez mcg...@suse.com Upstream Linux kernel commit c5905afb was introduced on v3.4 but git describe --contains yields v3.5 while if we use git to look for the first parent with git describe --first-parent yields v3.3. The reason for this seems to be that the merge commit that

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

2014-04-16 Thread Junio C Hamano
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

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

2014-04-16 Thread Luis R. Rodriguez
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