summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: 5fdcf75)
raw | patch | inline | side by side (parent: 5fdcf75)
author | Junio C Hamano <junkio@cox.net> | |
Thu, 24 May 2007 19:20:42 +0000 (12:20 -0700) | ||
committer | Junio C Hamano <junkio@cox.net> | |
Thu, 24 May 2007 20:36:54 +0000 (13:36 -0700) |
In git.git repository, "git-name-rev v1.3.0~158" cannot name the
rev, while adjacent revs can be named.
This was because it gives up traversal from the tips of existing
refs as soon as it sees a commit that has older commit timestamp
than what is being named. This is usually a good heuristics,
but v1.3.0~158 has a slightly older commit timestamp than
v1.3.0~157 (i.e. it's child), as these two were made in a
separate repostiory (in fact, in a different continent).
This adds a hardcoded slop value (1 day) to the cut-off
heuristics to work this kind of problem around. The current
algorithm essentially runs around from the available tips down
to ancient commits and names every single rev available that are
newer than cut-off date, so a single day slop would not add that
much overhead in repositories with long enough history where the
performance of name-rev matters.
I think the algorithm could be made a bit smarter by deepening
the graph on demand as a new commit is asked to be named (this
would require rewriting of name_rev() function not to recurse
itself but use a traversal list like revision.c traverser does),
but that would be a separate issue.
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
rev, while adjacent revs can be named.
This was because it gives up traversal from the tips of existing
refs as soon as it sees a commit that has older commit timestamp
than what is being named. This is usually a good heuristics,
but v1.3.0~158 has a slightly older commit timestamp than
v1.3.0~157 (i.e. it's child), as these two were made in a
separate repostiory (in fact, in a different continent).
This adds a hardcoded slop value (1 day) to the cut-off
heuristics to work this kind of problem around. The current
algorithm essentially runs around from the available tips down
to ancient commits and names every single rev available that are
newer than cut-off date, so a single day slop would not add that
much overhead in repositories with long enough history where the
performance of name-rev matters.
I think the algorithm could be made a bit smarter by deepening
the graph on demand as a new commit is asked to be named (this
would require rewriting of name_rev() function not to recurse
itself but use a traversal list like revision.c traverser does),
but that would be a separate issue.
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
builtin-name-rev.c | patch | blob | history |
diff --git a/builtin-name-rev.c b/builtin-name-rev.c
index ef1638590722017ad2cacca7ce30098fd0392bd5..2d94eaaa6a90f2efe4401873930533b12b85522f 100644 (file)
--- a/builtin-name-rev.c
+++ b/builtin-name-rev.c
#include "tag.h"
#include "refs.h"
+#define CUTOFF_DATE_SLOP 86400 /* one day */
+
static const char name_rev_usage[] =
"git-name-rev [--tags | --refs=<pattern>] ( --all | --stdin | committish [committish...] )\n";
add_object_array((struct object *)commit, *argv, &revs);
}
+ if (cutoff)
+ cutoff = cutoff - CUTOFF_DATE_SLOP;
for_each_ref(name_ref, &data);
if (transform_stdin) {