1

I want to use git bisect to fix some bugs.

git clone git@github.com:pingcap/tidb-engine-ext.git
git checkout raftstore-proxy
git bisect start
git bisect good 45ce5b9584d618bc777877be8a77cb94f61b8410
git bisect bad 8acb2b2ed0eb1576e7961149bde27cb1568ec39e

And it suggests me to check commit e868450a9f982b25790262c9e86ff1e27ab8dc2e, and I will call it mid.

It is quite strage when I start to check commit date of those commits

git show --no-patch --no-notes --pretty='%ci %ai' 45ce5b9584d618bc777877be8a77cb94f61b8410
# 2021-06-24 16:15:24 +0800 2021-06-24 16:15:24 +0800
git show --no-patch --no-notes --pretty='%ci %ai' e868450a9f982b25790262c9e86ff1e27ab8dc2e
# 2020-11-27 14:59:01 +0800 2020-11-27 14:59:01 +0800
git show --no-patch --no-notes --pretty='%ci %ai' 8acb2b2ed0eb1576e7961149bde27cb1568ec39e
# 2021-09-28 12:57:47 +0800 2021-09-27 13:50:37 +0800

I think commit date of e868450a9f982b25790262c9e86ff1e27ab8dc2e should be between [good,bad], even if we take potential cherry-pick/rebase into account, since every opertion will change commit date. So it is strage here.

Meanwhile, I also check if good and bad have common merge-base, and the result is yes. I think it means there is a chain that good -> ... -> bad, so I can bisect on this chain

git merge-base 45ce5b9584d618bc777877be8a77cb94f61b8410 8acb2b2ed0eb1576e7961149bde27cb1568ec39e
45ce5b9584d618bc777877be8a77cb94f61b8410

However, we I check merge base of bad/mid and mid/good, thing get stranger. It shows merge base of good and mid is neither good nor mid, but why does this happen?

git merge-base 45ce5b9584d618bc777877be8a77cb94f61b8410 e868450a9f982b25790262c9e86ff1e27ab8dc2e
# eb82614fc19345f363458e66b53aaff5c57563d5
git merge-base e868450a9f982b25790262c9e86ff1e27ab8dc2e 8acb2b2ed0eb1576e7961149bde27cb1568ec39e
# e868450a9f982b25790262c9e86ff1e27ab8dc2e
calvin
  • 2,125
  • 2
  • 21
  • 38
  • *Ignore the dates* on commits, because `git bisect` also ignores the dates on commits, because they may be wrong. Git should (and does) look only at the *commit graph* here. (There's some fancy commit graph optimization code in recent versions of Git, and some versions had some bugs. I don't think they ever affected `git bisect`, but that's possible. Still, you should ignore the dates.) – torek Oct 11 '21 at 07:40
  • But why merge base of good and mid is neither good nor mid? @torek – calvin Oct 11 '21 at 07:41
  • Why would you expect it to be? (It would be if the entire chain from good->mid->bad is linear, but otherwise it probably would not.) – torek Oct 11 '21 at 07:42
  • @torek Since `good -> bad` is linear, why shan't `good -> mid -> bad` be linear? – calvin Oct 11 '21 at 07:44
  • 1
    We don't know that `good->bad` is linear. All we know is `good` is an ancestor of `bad` (trivially true since that's an assumed starting condition). That's why the merge base of `good` and `bad` is `good`. But the merge base of `good` and `mid` may be elsewhere, as there may be additional ancestors to consider. – torek Oct 11 '21 at 07:49
  • @torek Alright, but what should I do next? continue to bisect? – calvin Oct 11 '21 at 07:52
  • Generally, yes. – torek Oct 11 '21 at 08:06

0 Answers0