0

I am trying to use git bisect. My good commit is

commit 7ce16e99296de1d559e7317adac6bc13a727ae2b
Author: ...
Date:   Tue Jun 22 14:52:54 2021 +0800

And my bad commit is

commit 8acb2b2ed0eb1576e7961149bde27cb1568ec39e
Author: ...
Date:   Mon Sep 27 13:50:37 2021 +0800

So I think when git bisect starts, it will give me a commit between Jun 22 2021 and Sep 27 2021.

However, it gives me a rather old one

commit 2f3971bcae715839ee8d2aea837a4bf4ce31c815
Merge: 2d32bba 5777bb6
Author: ...
Date:   Tue Dec 8 11:25:04 2020 +0800

I think it may be because of some merge issue, but why, and how can I solve this?

mkrieger1
  • 19,194
  • 5
  • 54
  • 65
calvin
  • 2,125
  • 2
  • 21
  • 38
  • 1
    "it will give me a commit between Jun 22 2021 and Sep 27 2021" not necessarily because "maybe because of some merge issue" is correct, like [if you cherry-picked](https://stackoverflow.com/q/48858262/114900). Given that, what do you want to solve? _Is that_ the commit that breaks your build? You can easily [see where the commit exists in your history](https://stackoverflow.com/questions/61510067/show-specific-commits-in-git-log-in-context-of-other-commits). – msanford Oct 09 '21 at 16:22
  • @msanford Do you suggest 2f3971bcae715839ee8d2aea837a4bf4ce31c815 is cherry picked? – calvin Oct 09 '21 at 16:28
  • It's that, or it's rebased, or some more manual method was used to set the author date. edit: to see what's going on with the dates, say `git log --graph --pretty=fuller --all --ancestry-path --not --glob=refs/bisect/good-*` – jthill Oct 09 '21 at 16:44
  • OK, seems very complicated to me. If I want git bisect to perform something like manually bisect over github.com/username/repo/commits/branch, how can I do that? @jthill – calvin Oct 09 '21 at 16:52
  • 4
    Just keep doing what you're doing and stop fixating on irrelevant details. You're trying to make the dates mean things they don't, that's what's confusing you. The complications are in your head. If you want to see the commit's position in the ancestry graph, show the part of the ancestry graph you're interested in and see where that commit is. – jthill Oct 09 '21 at 17:01
  • The more interesting date for this purpose is the commit date, not the author date. – Raymond Chen Oct 09 '21 at 17:49

1 Answers1

1

It's because the author date of a revision might be older than the time when the revision was brought into the branch. 2 simple scenarios:

  1. that commit was developed in a feature branch a long time ago. It was merged into the branch you are analizing between the two revisions that you are bisecting. In this case, git will notice that the problem is coming from a merge revision between the 2 revisions being bisected and will proceed to follow that branch, hence the older date.

  2. the revision was developed a long time ago... it was cherry-picked (or rebased) into the branch between the 2 revisions you are bisecting. The revision is between the 2 revisions.... but the author date won't be between the 2 dates of the revisions.

mkrieger1
  • 19,194
  • 5
  • 54
  • 65
eftshift0
  • 26,375
  • 3
  • 36
  • 60
  • I run `git show --no-patch --no-notes --pretty='%ci %ai' 2f3971bcae715839ee8d2aea837a4bf4ce31c815`, and it returns the same time `2020-12-08 11:25:04 +0800 2020-12-08 11:25:04 +0800` – calvin Oct 10 '21 at 01:21