Re: [PATCH 2/2] name-rev: favor describing with tags and use committer date to tiebreak
- Date: Fri, 17 Mar 2017 12:07:06 +0800
- From: Lars Schneider <larsxschneider@xxxxxxxxx>
- Subject: Re: [PATCH 2/2] name-rev: favor describing with tags and use committer date to tiebreak
> On 16 Mar 2017, at 06:50, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> "git name-rev" assigned a phony "far in the future" date to tips of
> refs that are not pointing at tag objects, and favored names based
> on a ref with the oldest date. This made it almost impossible for
> an unannotated tags and branches to be counted as a viable base,
> which was especially problematic when the command is run with the
> "--tags" option. If an unannotated tag that points at an ancient
> commit and an annotated tag that points at a much newer commit
> reaches the commit that is being named, the old unannotated tag was
> Update the "taggerdate" field of the rev-name structure, which is
> initialized from the tip of ref, to have the committer date if the
> object at the tip of ref is a commit, not a tag, so that we can
> optionally take it into account when doing "is this name better?"
> comparison logic.
> When "name-rev" is run without the "--tags" option, the general
> expectation is still to name the commit based on a tag if possible,
> but use non-tag refs as fallback, and tiebreak among these non-tag
> refs by favoring names with shorter hops from the tip. The use of a
> phony "far in the future" date in the original code was an effective
> way to ensure this expectation is held: a non-tag tip gets the same
> "far in the future" timestamp, giving precedence to tags, and among
> non-tag tips, names with shorter hops are preferred over longer
> hops, without taking the "taggerdate" into account. As we are
> taking over the "taggerdate" field to store the committer date for
> tips with commits:
> (1) keep the original logic when comparing names based on two refs
> both of which are from refs/tags/;
> (2) favoring a name based on a ref in refs/tags/ hierarchy over
> a ref outside the hierarchy;
> (3) between two names based on a ref both outside refs/tags/, give
> precedence to a name with shorter hops and use "taggerdate"
> only to tie-break.
> A change to t4202 is a natural consequence. The test creates a
> commit on a branch "side" and points at it with an unannotated tag
> "refs/tags/side-2". The original code couldn't decide which one to
> favor at all, and gave a name based on a branch (simply because
> refs/heads/side sorts earlier than refs/tags/side-2). Because the
> updated logic is taught to favor refs in refs/tags/ hierarchy, the
> the test is updated to expect to see tags/side-2 instead.
> Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
A quick bisect indicates that this patch might break
t9807-git-p4-submit.sh 8 and 13. I haven't looked into
it further, yet.