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 v3.4 and v9.0,
>> And in the real example case, why *would* c5905afb' be be described in
>> terms of v3.5 instead of v3.4 ?
> I am not interested in graphing that particular history between v3.4
> and v3.5 myself.  If you are interested, I already gave you enough
> information on how to figure that out.

I was alluding to another possible issue here, my concern was that the
commit's parent (which is not really the point at which it was merged,
but rather where the topic got forked off to be worked on) could be
used for as reference points but clearly its not given the nature of
how name-rev was implemented. I still do see some possible issues with
it's parent on other commands (but I haven't studied the other's
implementation) that reveals some of my original concerns, but its
unclear if they are related. I also found that if we didn't want to
rely on dates or start defining naming convention we may want to
reconsider the name_rev() recursive implementation. I'll illustrate a
few results that might help to show my concerns for both other
commands perhaps using the parent erroneously, and a possible
alternative implementation for name_rev() or at the very least

[0] mcgrof@ergon ~/linux (git::master)$ git log c5905afb..v3.5| grep
^commit | wc -l
[1] mcgrof@ergon ~/linux (git::master)$ git log c5905afb..v3.4| grep
^commit | wc -l
[2] mcgrof@ergon ~/linux (git::master)$ git log c5905afb..v3.3| grep
^commit | wc -l

Now that I revised name_rev.c I see the recursive nature of name_rev()
works top down from each tag down to each v* tag object and for each
actual commit pegs a name on it. How we rule out each tag under this
implementation is not that obvious to me, specially when results like
[0] and [1] reveal v3.4 should be 'shorter' in light of number of
commits. I see now how we don't update a commit's name if other
crucial information such as the ones discussed on this thread might be
important for the user, and I can see how this can help but an
alternative approach, which is what I expected to see implemented at
least for 'git describe --contains', would have been to see how many
commits are present from the commit's *merged* upstream parent (not
the actual parent as in c5905afb's commit case its v3.3 which is not
where it got merged). Getting the smallest number of commits under
this logic and stopping when we don't find any commits should yield us
the base tag under which the commit was merged, without any heuristics
on dates. This however applies to Linux though given that we don't
merge commits on stable branches but rather create new commits and
reference the upstream sha1sum, a practice which also solves the
problem Jeff pointed out.

The results for command [2] above however a bit surprising, I'd take a
look but I should go back to look at other stuff, figured I'd at least
bring it up now as it seems relevant.

>>>     - 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?
>> Sounds good to me!
> Not so fast ;-)
> My other message to Peff in response to his another example has an
> updated position on this.  "Reject candidates that can reach other
> candidates" is universally correct, but after that point, there are
> at least three but probably more options that suit preference of
> different people and project to break ties:
>  - Your case that started this thread may want to favor v3.4 if only
>    because that v3.4 _sounds_ smaller than v4.0 (in Peff's example),
>    even when v3.4 and v4.0 do not have ancestry relationship.
>  - The "closest" we have had is a heuristic to produce a result that
>    is textually shorter.
>  - And as I alluded to, "which one has the earliest timestamp?", is
>    another valid question to ask.

The first one above can be subjective if and only if the Linux
upstream model of dealing with stable branches is not followed. In
other words I think its a non issue if you create new commits on the
stable branches instead of merge stuff onto them. This however is
technical practice and I guess not everyone follows.

> And there may be more to appear.  A new command line option (and
> possibly a new configuration) to choose from these three (and more
> heuristics that will be added later) would be necessary.

Yeah this is rather complex, the resolutions to the issue in the ways
you've described seem reasonable to me but do wonder if this can be
simplified by reevaluating how the candidates are considered. You'd
know better :)

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

Reply via email to