Re: bug in name-rev on linux-2.6 repo?

From: Jeff King <peff@peff.net>
Date: Apr 22, 2010, 14:54 UTC
Message-ID: <20100422145455.GC28923@coredump.intra.peff.net>
In-Reply-To: <20100422144433.GB28923@coredump.intra.peff.net>

On Thu, Apr 22, 2010 at 10:44:33AM -0400, Jeff King wrote:

Show 24 quoted lines

> 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