Re: bisect-helper: we do not bisect --objects
From: "Junio C Hamano" <gitster@pobox.com>
Show 23 quoted lines
> 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@pobox.com>
> ---
>
> * 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
Show 19 quoted lines
> 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,
> Philip Oakley <philipoakley@iee.org>