4 ms·
A merge only workflow with replacement log tools to only show merge commits, and a better solution for CI and web presentation would basically fix git. People
by raggi 3y ago
A merge only workflow with replacement log tools to only show merge commits, and a better solution for CI and web presentation would basically fix git.
People have a ton of opinions on merge commits but they stem from very few real issues: The log UI is bad, bisect handles merges badly. That's basically the crux of it. If you "hid" the railroad tracks as any higher level solution does then most of the problem goes away. Unsurprisingly the issue is that investment on this path disappeared when the rebase people won, and now we're stuck with the least capable merge tool that git has as the way that everyone does everything. We kneecapped git, and it was us that did it to ourselves.
Edit: and rerere still is no where near as capable as merge.
- seeknotfind 3y agoWhen 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