From: Junio C Hamano <gitster@pobox.com>
To: Michael J Gruber <git@drmicha.warpmail.net>
Cc: git@vger.kernel.org
Subject: Re: [RFD PATCH 3/3] name-rev: Allow lightweight tags and branch refs
Date: Wed, 15 Mar 2017 13:51:56 -0700 [thread overview]
Message-ID: <xmqqd1die00j.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <xmqqlgs6e2uv.fsf@gitster.mtv.corp.google.com> (Junio C. Hamano's message of "Wed, 15 Mar 2017 12:50:32 -0700")
Junio C Hamano <gitster@pobox.com> writes:
> This could have been an invocation of "name-rev" without "--tags",
> where _any_ tip of ref can be used to name a revision, and in such a
> case, retaining commit->date may still be valuable, but it is
> probably wrong to use it for nothing more than tie-breaking.
> ...
> I think you can do this change _ONLY_ when we are operating under
> the "--tags" option. That would place unannotated tags at a better
> location in the timestamp order than the current code does, without
> introducing issues with refs that are actively moving.
I'll leave "only do so under --tags" as an exercise to the reader,
but if we want to use the timestamp for tie-breaking between names
based on two branches, a patch to do so may look like this one.
I am presenting it as a single ball of wax, but in the real history
I have (which I am not publishing, as I haven't decided if this is a
good direction to go in the first place), this is a two-patch
series, the first one that factors out is_better_name() without
doing anything else, followed by a commit that adds "from_tag" and
passes it throughout the callpath to allow is_better_name() to use
it to:
- always favor names based on a tag;
- between two names based on tags, favor name based on an older tag
and tiebreak with distance;
- between two names based on non-tags, favor name with shorter hops
and tiebreak with age.
builtin/name-rev.c | 43 ++++++++++++++++++++++++++++++++++++-------
1 file changed, 36 insertions(+), 7 deletions(-)
diff --git a/builtin/name-rev.c b/builtin/name-rev.c
index cd89d48b65..ba30c9ca23 100644
--- a/builtin/name-rev.c
+++ b/builtin/name-rev.c
@@ -13,6 +13,7 @@ typedef struct rev_name {
unsigned long taggerdate;
int generation;
int distance;
+ int from_tag;
} rev_name;
static long cutoff = LONG_MAX;
@@ -20,9 +21,31 @@ static long cutoff = LONG_MAX;
/* How many generations are maximally preferred over _one_ merge traversal? */
#define MERGE_TRAVERSAL_WEIGHT 65535
+static int is_better_name(struct rev_name *name,
+ const char *tip_name,
+ unsigned long taggerdate,
+ int generation,
+ int distance,
+ int from_tag)
+{
+ if (name->from_tag > from_tag)
+ return 0;
+ else if (name->from_tag < from_tag)
+ return 1;
+
+ if (from_tag)
+ return (name->taggerdate > taggerdate ||
+ (name->taggerdate == taggerdate &&
+ name->distance > distance));
+ else
+ return (name->distance > distance ||
+ (name->distance == distance &&
+ name->taggerdate > taggerdate));
+}
+
static void name_rev(struct commit *commit,
const char *tip_name, unsigned long taggerdate,
- int generation, int distance,
+ int generation, int distance, int from_tag,
int deref)
{
struct rev_name *name = (struct rev_name *)commit->util;
@@ -45,14 +68,14 @@ static void name_rev(struct commit *commit,
name = xmalloc(sizeof(rev_name));
commit->util = name;
goto copy_data;
- } else if (name->taggerdate > taggerdate ||
- (name->taggerdate == taggerdate &&
- name->distance > distance)) {
+ } else if (is_better_name(name, tip_name, taggerdate,
+ generation, distance, from_tag)) {
copy_data:
name->tip_name = tip_name;
name->taggerdate = taggerdate;
name->generation = generation;
name->distance = distance;
+ name->from_tag = from_tag;
} else
return;
@@ -72,10 +95,12 @@ static void name_rev(struct commit *commit,
parent_number);
name_rev(parents->item, new_name, taggerdate, 0,
- distance + MERGE_TRAVERSAL_WEIGHT, 0);
+ distance + MERGE_TRAVERSAL_WEIGHT,
+ from_tag, 0);
} else {
name_rev(parents->item, tip_name, taggerdate,
- generation + 1, distance + 1, 0);
+ generation + 1, distance + 1,
+ from_tag, 0);
}
}
}
@@ -174,9 +199,13 @@ static int name_ref(const char *path, const struct object_id *oid, int flags, vo
}
if (o && o->type == OBJ_COMMIT) {
struct commit *commit = (struct commit *)o;
+ int from_tag = starts_with(path, "refs/tags/");
+ if (taggerdate == ULONG_MAX)
+ taggerdate = ((struct commit *)o)->date;
path = name_ref_abbrev(path, can_abbreviate_output);
- name_rev(commit, xstrdup(path), taggerdate, 0, 0, deref);
+ name_rev(commit, xstrdup(path), taggerdate, 0, 0,
+ from_tag, deref);
}
return 0;
}
next prev parent reply other threads:[~2017-03-15 20:52 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-15 13:15 [PATCH 0/3] describe --contains sanity Michael J Gruber
2017-03-15 13:15 ` [PATCH 1/3] describe: debug is incompatible with contains Michael J Gruber
2017-03-15 19:21 ` Junio C Hamano
2017-03-17 10:54 ` Michael J Gruber
2017-03-15 13:15 ` [PATCH 2/3] git-prompt: add a describe style for any tags Michael J Gruber
2017-03-15 19:25 ` Junio C Hamano
2017-03-17 10:56 ` Michael J Gruber
2017-03-15 13:15 ` [RFD PATCH 3/3] name-rev: Allow lightweight tags and branch refs Michael J Gruber
2017-03-15 16:14 ` Junio C Hamano
2017-03-15 19:50 ` Junio C Hamano
2017-03-15 20:51 ` Junio C Hamano [this message]
2017-03-15 22:50 ` [PATCH 0/2] Teach name-rev to pay more attention to lightweight tags Junio C Hamano
2017-03-15 22:50 ` [PATCH 1/2] name-rev: refactor logic to see if a new candidate is a better name Junio C Hamano
2017-03-15 22:50 ` [PATCH 2/2] name-rev: favor describing with tags and use committer date to tiebreak Junio C Hamano
2017-03-17 4:07 ` Lars Schneider
2017-03-17 5:45 ` Junio C Hamano
2017-03-17 5:56 ` Junio C Hamano
2017-03-17 17:09 ` Lars Schneider
2017-03-17 17:17 ` Junio C Hamano
2017-03-17 22:43 ` Junio C Hamano
2017-03-29 14:39 ` [PATCH v2 0/3] name-rev sanity Michael J Gruber
2017-03-29 14:39 ` [PATCH v2 1/3] name-rev: refactor logic to see if a new candidate is a better name Michael J Gruber
2017-03-29 14:39 ` [PATCH v2 2/3] name-rev: favor describing with tags and use committer date to tiebreak Michael J Gruber
2017-03-29 14:39 ` [PATCH v2 3/3] name-rev: provide debug output Michael J Gruber
2017-03-29 17:15 ` [PATCH v2 0/3] name-rev sanity Junio C Hamano
2017-03-29 17:43 ` Junio C Hamano
2017-03-30 13:48 ` Michael J Gruber
2017-03-30 17:30 ` Junio C Hamano
2017-03-31 13:51 ` [PATCH v3 0/4] " Michael J Gruber
2017-03-31 13:51 ` [PATCH v3 1/4] name-rev: refactor logic to see if a new candidate is a better name Michael J Gruber
2017-03-31 13:51 ` [PATCH v3 2/4] name-rev: favor describing with tags and use committer date to tiebreak Michael J Gruber
2017-03-31 13:51 ` [PATCH v3 3/4] name-rev: provide debug output Michael J Gruber
2017-03-31 16:52 ` Junio C Hamano
2017-03-31 16:55 ` Junio C Hamano
2017-03-31 18:02 ` Michael J Gruber
2017-03-31 18:06 ` Junio C Hamano
2017-03-31 18:33 ` Junio C Hamano
2017-04-03 14:46 ` Michael J Gruber
2017-04-03 17:07 ` Junio C Hamano
2017-05-20 5:19 ` Junio C Hamano
2017-03-31 19:10 ` Junio C Hamano
2017-03-31 13:51 ` [PATCH v3 4/4] describe: pass --debug down to name-rev Michael J Gruber
2017-03-17 11:25 ` [PATCH 2/2] name-rev: favor describing with tags and use committer date to tiebreak Michael J Gruber
2017-03-17 16:03 ` Junio C Hamano
2017-03-16 0:14 ` [PATCH 0/2] Teach name-rev to pay more attention to lightweight tags Stefan Beller
2017-03-16 10:28 ` Jacob Keller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqd1die00j.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).