From: Philip Oakley Date: Fri, 03 Mar 2017 23:28:39 GMT Subject: Re: bisect-helper: we do not bisect --objects Message-ID: In-Reply-To: From: "Junio C Hamano" > 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 > --- > > * 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, >