3 ms·
I'd prefer it not be magic. Just because git COULD merge two of the same line changes doesn't mean it SHOULD. Maybe you have two vastly different methods to so
by tomschlick 10y ago
I'd prefer it not be magic. Just because git COULD merge two of the same line changes doesn't mean it SHOULD.
Maybe you have two vastly different methods to solving the same problem and now they are both in there and both not working instead of leaving it up to the merger to decide.
- Bartweiss 10y agoThis seems like a clear case of unequal tradeoffs. There are a couple of conflict patterns that are particularly easy to identify, which git could merge smoothly. For instance, two unrelated code blocks are appended to the bottom of the same file - whoever merged those two probably wants to keep both in any order. But if you don't want that behavior, git is going to quietly auto-merge a bad change. That's easily 10x as bad as the time savings is good, maybe 100x. So I agree - this should not be magic, and I'm pretty sure the design for auto-merge hits practical limits long before technical ones.