Web lists-archives.com

Re: bisect-helper: we do not bisect --objects




From: "Junio C Hamano" <gitster@xxxxxxxxx>
Ever since "bisect--helper" was introduced in 1bf072e366
("bisect--helper: implement "git bisect--helper"", 2009-03-26),
after setting up the "rev-list $bad --not $good_ones" machinery, the
code somehow prepared to mark the trees and blobs at the good boundary
as uninteresting, only when --objects option was given.  This was kept
across a bit of refactoring done by 2ace9727be ("bisect: move common
bisect functionality to "bisect_common"", 2009-04-19) and survives
to this day.

However, "git bisect" does not care about tree/blob object
reachability at all---it purely works at the commit DAG level and
nobody passes (and nobody should pass) "--objects" option to the
underlying rev-list machinery.  Remove the dead code.

Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
---

* Christian, do you recall what we were thinking when we added this
  mark_edges_uninteresting() call in this program?  If you don't,
  don't worry--this was done more than 8 years ago.  I am just
  being curious and also a bit being cautious in case I am missing
  something.


Bikeshedding: If the given boundary is a tag, it could be tagging a blob or tree rather than a commit. Would that be a scenario that reaches this part of the code? I thought I read previous comments that there is a case in the Linux tree.
--
Philip

  Thanks.

bisect.c | 2 --
1 file changed, 2 deletions(-)

diff --git a/bisect.c b/bisect.c
index 30808cadf7..86c5929a23 100644
--- a/bisect.c
+++ b/bisect.c
@@ -634,8 +634,6 @@ static void bisect_common(struct rev_info *revs)
{
 if (prepare_revision_walk(revs))
 die("revision walk setup failed");
- if (revs->tree_objects)
- mark_edges_uninteresting(revs, NULL);
}

static void exit_if_skipped_commits(struct commit_list *tried,