Hacker News Reader

Pick 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

View on HN

Is 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

For reference, `git log --topo-order` docs: https://git-scm.com/docs/git-log#Documentation/git-log.txt--...

Reply on news.ycombinator.com