From: "Marc Haber" <mh+git-us...@zugschlus.de>
On Mon, Dec 25, 2017 at 11:21:36PM -0000, Philip Oakley wrote:
Possibly include more good commits in the list. I suspect that there are
multiple branches that merge into master between those two tags, and that
some of those brancfes have fork points from before the given good tag,
so
git has to search down all of those other side branches, and found one.
Hence the report of an rc branch as the first bad commit.
Assuming that it would probably not help including commits that were
marked as good in the first bisect, How would I choose such commits?
Unfortunately, it takes multiple days to be reasonably (but not even
then absolutely) sure that a commit is "good". It is significantly
more easy to identify a "bad" commit with this issue.
Hi Mark,
The key points were that bisect will search *all* heirarchy paths (unless
you tell it different). This means that all side heirarchies are also places
that bisect will search.
Each time you give a 'good' history point it will trim the search history.
IIRC you can also use the parsing options such as --first-parent to limit
the search history (so you find the point that the bad issue was merged in).
It has commonly (a few times) come up on the Git devs list about a Linux
bisect reporting an rc candidate from before the given good tag. In all
those cases (as I remember it), this was because the Linux branch and merge
philosophy is geared to the strengths and capabilities of Git, rather than
the weaknesses of historic(*) version control.
In particular, part of a patch from a commit prior (in time) to the known
good release tag, can still be on the heirarchy "between" the good and bad
tag, because it was merged in from some side branch that had bypassed the
good tag, so provides an alternate route for something from history to be
present in the current 'bad' tag.
One thing to do is to use 'git describe' for the good tag/commit and the
commit found by the bisect and look at the implied history of the
^I~J^K~L^M~N history flows, I guess that you will find that the bisected
commit is from such a side branch.
--
Philip
(*) most version control is based on drawing office practice that predates
the Bismark or the Titanic. If the original clean drawing was damaged then
the design was lost. All processes were there to protect that 'master'
drawing (old masters and drwg masters were equally valueable). This
proceeded into computers via Hollerith cards. It was only with Git (and its
predecessor) that the perfect replication and hash based
authentication/validation (by computers) was brought together to remove the
"control" element from the single line of history (one master) approach.
That, coupled with easy diffs and merging for small changes, has allowed
Linux to make such great progress. But unlearning the old CM (configuration
management) perspectives can be hard - nobody mentions the implicit rules
that Git breaks!
Look for the merge base between the found bad commit and your given good tag
to see where it branched off.
--
You received this message because you are subscribed to the Google Groups "Git for
human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
