On Thu, Apr 22, 2010 at 10:44:33AM -0400, Jeff King wrote:
> Hmm. Maybe clock skew in the commit timestamps is at fault? With this
> patch to git:
>
> diff --git a/builtin/name-rev.c b/builtin/name-rev.c
> index 06a38ac..7a024ab 100644
> --- a/builtin/name-rev.c
> +++ b/builtin/name-rev.c
> @@ -29,9 +29,6 @@ static void name_rev(struct commit *commit,
> if (!commit->object.parsed)
> parse_commit(commit);
>
> - if (commit->date < cutoff)
> - return;
> -
> if (deref) {
> char *new_name = xmalloc(strlen(tip_name)+3);
> strcpy(new_name, tip_name);
>
> I get:
>
> $ $ git name-rev a1de02dccf906faba2ee2d99cac56799bda3b96a
> a1de02dccf906faba2ee2d99cac56799bda3b96a tags/v2.6.34-rc1~199^2~35
>
> but I haven't tracked down the problematic commit and timestamp yet.
Still looking, but definitely some kind of skew problem. Reverting the
patch above and doing this also works:
diff --git a/builtin/name-rev.c b/builtin/name-rev.c
index 06a38ac..198e04d 100644
--- a/builtin/name-rev.c
+++ b/builtin/name-rev.c
@@ -5,7 +5,7 @@
#include "refs.h"
#include "parse-options.h"
-#define CUTOFF_DATE_SLOP 86400 /* one day */
+#define CUTOFF_DATE_SLOP (60*86400)
typedef struct rev_name {
const char *tip_name;
but a 59-day slop does not.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html