4 ms·
When commits from two or more parents have to interact in order to produce a bug, I don't think there is a bisect algorithm that can actually identify that bug.
by seeknotfind 3y ago
When commits from two or more parents have to interact in order to produce a bug, I don't think there is a bisect algorithm that can actually identify that bug. There isn't enough data to automatically merge prefixes of the merge history from respective parents in order to test them against each other. Also, the search space in this case becomes the product of the number of commits from the LCA to each parent. So I really don't understand how we messed up.
I'm just glad we have "--rebase-merges" now because when you have two git servers that are actually important enough not to rebase their history, you do need merges.
- raggi 3y agoPick a linearization strategy and walk it, this isn’t all that different from the “confusing history problem”, which is largely solved by —topo-order which is not the default because it’s slower
- roryokane 3y agoFor reference, `git log --topo-order` docs: https://git-scm.com/docs/git-log#Documentation/git-log.txt---topo-order https://git-scm.com/docs/git-log#Documentation/git-log.txt--...
- seeknotfind 3y agoIs there a way to use this with bisect? Once you use merges, you aren't guaranteed to be able to apply the commits in the topo-order in a safe way. For instance if one parent changes the text of a file AA -> AB -> AC and one changes the text AA -> ABA -> ACA, the merge commit contains information to combine AC/ACA, but there is no information stored on how to resolve AB/ABA (or other combinations), so if intermediate states conflict, you can no longer bisect. edit: and if you pick a specific order as you are suggesting to reduce the search space, then it's unclear how to resolve applying ABA on top of AC, for instance