[PATCH] rerere: fix an off-by-one non-bug

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



When ac49f5ca (rerere "remaining", 2011-02-16) created a new helper
function check_one_conflict() out of find_conflict() function, and
made the latter use the returned value from the new helper to update
the loop control variable that is an index into the active_cache[],
the new variable was incremented by one too many when it pointed at
a path with only stage #1 entry at the very end of the cache.

This "strange" return value does not have any effect on the loop
control of two callers of this function, as they all notice that
active_nr+2 is larger than active_nr just like active_nr+1 is, but
nevertheless it puzzles the readers when they are trying to figure
out what the function is trying to do.

Help future readers from unnecessary confusion by dropping an
unnecessary +1 from the returned value..

Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
---
 rerere.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rerere.c b/rerere.c
index 31644de..543df47 100644
--- a/rerere.c
+++ b/rerere.c
@@ -371,7 +371,7 @@ static int check_one_conflict(int i, int *type)
 	*type = PUNTED;
 	if (ce_stage(e) == 1) {
 		if (active_nr <= ++i)
-			return i + 1;
+			return i;
 	}
 
 	/* Only handle regular files with both stages #2 and #3 */
-- 
2.5.0-rc0-168-g2f1df93

--
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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]