Hi
The default git-bisect algorithm will jump around the commit tree,
on the purpose of taking least steps to find the first culprit commit.
We may find it sometime would locate a old culprit commit that we're not
concerned about anymore.
In most software development, there's one or two main branch which
is maintained for release, and a bunch of feature branches are created
for new feature development or bug fix. For the reason that sometime
git-bisect will locate a old culprit commit would be:
1. Quality of those branches may not match the main branch,
some functionality are broken at first and fixed later on the feature
branch. If git-bisect jump to there by chance, git-bisect will only find that old
culprit commit which only exists on that feature branch
2. Some of those branches may not synchronized with main
branch in time. Say feature1 is broken when feature2 branch is created, and
feature1 is fixed just a moment later after feature2 branch is created,
and when feature2's development is done, and developer want to merge
feature2 branch back to master branch, feature2 will be firstly
synchronized to master branch tip, then merge into master. For the same
reason addressed in issue 1, this will also lead git-bisect into wrong
direction. In all, we think we do not care about branches that we're not
currently working, unless we're sure the regression is caused by that
branch.
To address those issue, we propose to add a new config option:
core.bisectbadbranchfirst::
With this algorithm, git-bisect will always try to select
commits
that on the same branch current bad commit sits. And will
fall back
to default git-bisect algorithm when bad-branch-first
algorithm does
not apply
+
This setting defaults to "false". The draft patch will be sent out in a later email, so it could be
reviewed inline.
Any question or suggestion is welcome :-)Thanks
--Shuang