4 ms·
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 n
by raggi 3y ago
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
- 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