[PATCH] name-rev: include taggerdate in considering the best name

[PATCH] name-rev: include taggerdate in considering the best name

[Johannes Schindelin]

We most likely want the oldest tag that contained the commit to be
reported. So let's remember the taggerdate, and make it more important
than anything else when choosing the best name for a given commit.

Suggested by Linus Torvalds.

Note that we need to update t9903 because it tested for the old behavior
(which preferred the description "b1~1" over "tags/t2~1").

We might want to introduce a --heed-taggerdate option, and make the new
behavior dependent on that, if it turns out that some scripts rely on the
old name-rev method.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 builtin/name-rev.c     | 19 +++++++++++++------
 t/t9903-bash-prompt.sh |  2 +-
 2 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/builtin/name-rev.c b/builtin/name-rev.c
index 092e03c..57be35f 100644
--- a/builtin/name-rev.c
+++ b/builtin/name-rev.c
@@ -10,6 +10,7 @@
 
 typedef struct rev_name {
 	const char *tip_name;
+	unsigned long taggerdate;
 	int generation;
 	int distance;
 } rev_name;
@@ -20,7 +21,8 @@ static long cutoff = LONG_MAX;
 #define MERGE_TRAVERSAL_WEIGHT 65535
 
 static void name_rev(struct commit *commit,
-		const char *tip_name, int generation, int distance,
+		const char *tip_name, unsigned long taggerdate,
+		int generation, int distance,
 		int deref)
 {
 	struct rev_name *name = (struct rev_name *)commit->util;
@@ -43,9 +45,12 @@ static void name_rev(struct commit *commit,
 		name = xmalloc(sizeof(rev_name));
 		commit->util = name;
 		goto copy_data;
-	} else if (name->distance > distance) {
+	} else if (name->taggerdate > taggerdate ||
+			(name->taggerdate == taggerdate &&
+			 name->distance > distance)) {
 copy_data:
 		name->tip_name = tip_name;
+		name->taggerdate = taggerdate;
 		name->generation = generation;
 		name->distance = distance;
 	} else
@@ -66,11 +71,11 @@ copy_data:
 				new_name = xstrfmt("%.*s^%d", (int)len, tip_name,
 						   parent_number);
 
-			name_rev(parents->item, new_name, 0,
+			name_rev(parents->item, new_name, taggerdate, 0,
 				distance + MERGE_TRAVERSAL_WEIGHT, 0);
 		} else {
-			name_rev(parents->item, tip_name, generation + 1,
-				distance + 1, 0);
+			name_rev(parents->item, tip_name, taggerdate,
+				generation + 1, distance + 1, 0);
 		}
 	}
 }
@@ -140,6 +145,7 @@ static int name_ref(const char *path, const struct object_id *oid, int flags, vo
 	struct name_ref_data *data = cb_data;
 	int can_abbreviate_output = data->tags_only && data->name_only;
 	int deref = 0;
+	unsigned long taggerdate = ULONG_MAX;
 
 	if (data->tags_only && !starts_with(path, "refs/tags/"))
 		return 0;
@@ -164,12 +170,13 @@ static int name_ref(const char *path, const struct object_id *oid, int flags, vo
 			break; /* broken repository */
 		o = parse_object(t->tagged->oid.hash);
 		deref = 1;
+		taggerdate = t->date;
 	}
 	if (o && o->type == OBJ_COMMIT) {
 		struct commit *commit = (struct commit *)o;
 
 		path = name_ref_abbrev(path, can_abbreviate_output);
-		name_rev(commit, xstrdup(path), 0, 0, deref);
+		name_rev(commit, xstrdup(path), taggerdate, 0, 0, deref);
 	}
 	return 0;
 }
diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh
index ffbfa0e..0db4469 100755
--- a/t/t9903-bash-prompt.sh
+++ b/t/t9903-bash-prompt.sh
@@ -107,7 +107,7 @@ test_expect_success 'prompt - describe detached head - contains' '
 '
 
 test_expect_success 'prompt - describe detached head - branch' '
-	printf " ((b1~1))" >expected &&
+	printf " ((tags/t2~1))" >expected &&
 	git checkout b1^ &&
 	test_when_finished "git checkout master" &&
 	(
-- 
2.8.1.207.g7b140d3

Re: [PATCH] name-rev: include taggerdate in considering the best name

[Jeff King]

On Fri, Apr 22, 2016 at 03:39:01PM +0200, Johannes Schindelin wrote:

> We most likely want the oldest tag that contained the commit to be
> reported. So let's remember the taggerdate, and make it more important
> than anything else when choosing the best name for a given commit.
> 
> Suggested by Linus Torvalds.
> 
> Note that we need to update t9903 because it tested for the old behavior
> (which preferred the description "b1~1" over "tags/t2~1").
> 
> We might want to introduce a --heed-taggerdate option, and make the new
> behavior dependent on that, if it turns out that some scripts rely on the
> old name-rev method.
> 
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>  builtin/name-rev.c     | 19 +++++++++++++------
>  t/t9903-bash-prompt.sh |  2 +-
>  2 files changed, 14 insertions(+), 7 deletions(-)

That turned out to be quite simple (I wasn't sure originally if we'd
actually visit all of the tags, which is why I had conceived of this as
an initial pass; but of course it makes sense that we'd have to see all
of the tags in the existing code).

I confirmed that it does find the "optimal" tag for the case we've been
discussing.

We could _also_ tweak the merge-weight as Linus's patch did, just
because 10000 has more basis than 65535. But I think it really matters a
lot less at this point.

-Peff

Re: [PATCH] name-rev: include taggerdate in considering the best name

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> That turned out to be quite simple (I wasn't sure originally if we'd
> actually visit all of the tags, which is why I had conceived of this as
> an initial pass; but of course it makes sense that we'd have to see all
> of the tags in the existing code).
> ...
> We could _also_ tweak the merge-weight as Linus's patch did, just
> because 10000 has more basis than 65535. But I think it really matters a
> lot less at this point.

I agree, but if we were to go this route of keeping track of "some"
attribute of the tip the traversal started from, I wonder if it is
better to keep the actual tag object, not just its tagger date as an
unsigned long, in the new field.

That way, a tweak may be able to even use the v:refname comparison
if we wanted to do so in the future.  It is easy to go from a tag
object to its tagger date, but it is impossible to go in the other
direction, i.e. given a tagger date to go back to the tag.

Re: [PATCH] name-rev: include taggerdate in considering the best name

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Jeff King <peff@peff.net> writes:
>
>> That turned out to be quite simple (I wasn't sure originally if we'd
>> actually visit all of the tags, which is why I had conceived of this as
>> an initial pass; but of course it makes sense that we'd have to see all
>> of the tags in the existing code).
>> ...
>> We could _also_ tweak the merge-weight as Linus's patch did, just
>> because 10000 has more basis than 65535. But I think it really matters a
>> lot less at this point.
>
> I agree, but if we were to go this route of keeping track of "some"
> attribute of the tip the traversal started from, I wonder if it is
> better to keep the actual tag object, not just its tagger date as an
> unsigned long, in the new field.

Actually, I take it back.  The "object" approach would not give us
enough flexibility to go beyond "date".  A light-weight tag that
directly point at a commit object can still yield "date" (probably
"committerdate" to be compared with other dates, be it the committer
date from another commit or the tagger date from a real tag), but if
we later wanted to do a v:refname kind of comparison, we'd need to
keep the name of the ref (we cannot go back from the commit object
to the refname), so at that point, we would be talking about adding
yet another field anyway to hold the refname, in addition to the
field we would be adding at this step.  As we do not want to be
always doing "name to object to date" conversion in this codepath,
adding an "unsigned long" date field is the right thing to do here.
A more elaborate future can add refname (or refname and object) as
additional fields, but we can wait because even after that update
the codepath to do date comparison likely would want to have direct
access to the date field anyway.

Re: [PATCH] name-rev: include taggerdate in considering the best name

[Linus Torvalds]

On Fri, Apr 22, 2016 at 11:11 AM, Jeff King <peff@peff.net> wrote:
>
> I confirmed that it does find the "optimal" tag for the case we've been
> discussing.

Yes. I'm a bit more worried about the date behavior for projects that
merge back stable branches into their development trees (is the
development tag better than the stable tag? the date doesn't really
say much), but I think this is still the simplest model we can use
without trying to really do a topo-sort. And in many ways it's the
simplest one to explain to people too: "we try to use the oldest
reference we can find as a base for the resulting name" is not a
complex or hard concept to explain.

> We could _also_ tweak the merge-weight as Linus's patch did, just
> because 10000 has more basis than 65535. But I think it really matters a
> lot less at this point.

Yes. I still think that my tweak makes more sense than the existing
code, but it's a tiny tweak, compared to the date-based approach.
Unlikely to ever matter much.

            Linus

Re: [PATCH] name-rev: include taggerdate in considering the best name

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> ... I think this is still the simplest model we can use
> without trying to really do a topo-sort. And in many ways it's the
> simplest one to explain to people too: "we try to use the oldest
> reference we can find as a base for the resulting name" is not a
> complex or hard concept to explain.

Yes, the more I look at Dscho's patch, the more like it exactly for
that reason.  Its behaviour is very simple from the end-user's point
of view, unlike the historical one.

Re: [PATCH] name-rev: include taggerdate in considering the best name

[Johannes Schindelin]

Hi,

[fixing Uwe's email address, as the address bounces that was recorded in
the commit introducing the flawed behavior, and I failed to check mailmap
earlier.]

On Fri, 22 Apr 2016, Junio C Hamano wrote:

> Linus Torvalds <torvalds@linux-foundation.org> writes:
> 
> > ... I think this is still the simplest model we can use
> > without trying to really do a topo-sort. And in many ways it's the
> > simplest one to explain to people too: "we try to use the oldest
> > reference we can find as a base for the resulting name" is not a
> > complex or hard concept to explain.
> 
> Yes, the more I look at Dscho's patch, the more like it exactly for
> that reason.  Its behaviour is very simple from the end-user's point
> of view, unlike the historical one.

Well, seeing as I introduced the bug, it's only fair that I fix it, too.

Ciao,
Dscho