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 point of view, it is *WRONG*.
>
> It is wrong because v9.0 can reach v3.4. 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 contain another
> candidate tag, rejecting v3.5 (not shown) and v9.0;
>
> - among the surviving tags, pick the closest.
>
> Hmm?
Interesting. I think that would cover some cases, but there are others
in which the tags are not direct descendants. For example, imagine you
have both a "master" and a "maint" branch. You fork a topic from an old
commit that both branches contain, and then independently merge the
topic to each branch. You then cut a release for each. So your graph
might look like:
---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 description of J?
By the rules above, we hit the third rule "pick the closest". Which
means we choose v3.4 or v4.0 based solely on how many commits are
between the topic's merge and the tag release. Which has nothing at all
to do with the topic itself.
In this case we'd show v4.0 (because "J-H-I" is shorter than "J-D-E-F").
But I suspect most users would want to know v3.4, because they want to
know the "oldest" release they can move up to that contains the commit.
But that notion of oldness is not conveyed by the graph above; it's only
an artifact of the tag names.
So you can solve this by actually representing the relationship with a
merge. IOW, by merging v3.4 into v4.0 to say "yes, v4.0 is a superset".
And that's generally what we do in git.git, merging maint into master
periodically. But I imagine there are other possible workflows where
people do not do that "merge up", and the maint and master branches
diverge (and maybe they even cherry-pick from each other, but sometimes
merge if the fix can be based on a common ancestor, as in this case).
-Peff
--
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