[RFC/PATCH] bisect: clean flags after checking merge bases

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

 



Unless there is a good reason to belieave that a particular
invocation of a get_merge_bases*() is the last one that cares about
the object flags the computation of merge bases leaves on the
objects, the "cleanup" parameter should always be true, and I do not
think there is one in this codepath.

Found by code inspection.

Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
---
 * I am planning to eventually change the function signature for
   this function to drop "cleanup" and change rare selected
   codepaths that know what they are doing to call a separate
   function that allows the flags not to be cleaned up.  Two calls
   in builtin/merge-base.c are both the last ones that can leave the
   flags on the objects, but I do not think this one, which happens
   before the main traversal even starts, should pass 0 here.

 bisect.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bisect.c b/bisect.c
index df09cbc..ccca3b5 100644
--- a/bisect.c
+++ b/bisect.c
@@ -777,7 +777,7 @@ static void check_merge_bases(int no_checkout)
 	int rev_nr;
 	struct commit **rev = get_bad_and_good_commits(&rev_nr);
 
-	result = get_merge_bases_many(rev[0], rev_nr - 1, rev + 1, 0);
+	result = get_merge_bases_many(rev[0], rev_nr - 1, rev + 1, 1);
 
 	for (; result; result = result->next) {
 		const unsigned char *mb = result->item->object.sha1;
--
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]