Skip to contentSkip to conversation

name-rev: use larger timestamp for is_better_name

PATCH In review Eric Wong 3 participants 3 messages May 20, 2017

lore
Share & tools
lore

Eric Wong

author
#0 lore raw

PATCH 1/1 name-rev: use larger timestamp for is_better_name

This fixes t4202 for me at "44 - log --graph with full output" on 32-bit x86.

---
This is for pu, I'm still using the machine I used git with in 2005 :)

 builtin/name-rev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
builtin/name-rev.c +1 -1
index f06498524..35409c03b 100644
@@ -27,7 +27,7 @@ static const char *prio_names[] = {
 
 static int is_better_name(struct rev_name *name,
 			  const char *tip_name,
-			  unsigned long taggerdate,
+			  timestamp_t taggerdate,
 			  int generation,
 			  int distance,
 			  int from_tag)
Signature · 1 line
EW
#1 lore raw
Quoted 16 lines · Eric Wong

This fixes t4202 for me at "44 - log --graph with full output" on 32-bit x86.

---
This is for pu, I'm still using the machine I used git with in 2005 :)

 builtin/name-rev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
builtin/name-rev.c +0 -0
index f06498524..35409c03b 100644

builtin/name-rev.c static const char *prio_names[] = { · line 33

Quoted 8 lines
builtin/name-rev.c +1 -1
@@ -27,7 +27,7 @@ static const char *prio_names[] = {
 
 static int is_better_name(struct rev_name *name,
 			  const char *tip_name,
-			  unsigned long taggerdate,
+			  timestamp_t taggerdate,
 			  int generation,
 			  int distance,
 			  int from_tag)

Heh, you seem to be a little ahead of me. :-D

I test on 32-bit Linux from time to time, and tonight's 'pu' branch fails t4202.44, t6007.2,5-6,12-13,16, t6012.2-11, t6111.2-65. I bisected the t4202 failure to a merge commit (99d31e1378, merge branch 'jc/name-rev-lw-tag') and I spotted the 'unsigned long' taggerdate parameter to the is_better_name() function.

I was just about to try the patch above and retest, when I saw your email! (so I can leave that for tonight).

Thanks!

ATB,
Ramsay Jones

#2 lore raw
Quoted 6 lines · Ramsay Jones

I test on 32-bit Linux from time to time, and tonight's 'pu' branch fails t4202.44, t6007.2,5-6,12-13,16, t6012.2-11, t6111.2-65. I bisected the t4202 failure to a merge commit (99d31e1378, merge branch 'jc/name-rev-lw-tag') and I spotted the 'unsigned long' taggerdate parameter to the is_better_name() function.

Thanks. My earlier "oh, cutoff that was long also is a timestamp" patch was what I did while making this exact "evil merge" change, and then when I re-integrated everything, I forgot about it.

I'll teach my rerere database about this. Thanks.