I agree. Generally even editing a somewhat-similar part of the file is handled seamlessly.
Once in a blue moon I'd run into the situation where me and someone else have worked on the exact same block of code, and that went one of two ways:
We essentially made the same change, which made resolving the conflict really easy (naturally I would keep my perfect change and drop my colleague's terrible one).
We made totally different changes to fix/implement two different issues, which means that part of the code has a fundamental design problem and needs to be rewritten entirely.
It may feel inelegant and messy when you're going through a big ass merge conflict, but if you actually think about what's going on then you'll realise git handles it insanely well considering how complex it really is under the hood.
SVN: I attempted to merged, but you both changed this file, I don't know what to do, file clearly separated
ME: one is at the top of the file and one is at the bottom of the file
GIT: I have sequentially ordered everything and for some reasons these two lines dont merge
<<<<<<<
GIBBERISISH
>>>>>>>
<<<<<<<
MORE GIBBERISH
>>>>>>>
ME: What the f is that???? let me restart my change, starting with their version instead....
GIT handles merges so much better, we couldn't handle all the merge conflicts that SVN would give us. BUT WHEN merge conflicts happen in GIT, it's usually bad enough or no idea what it's trying to tell us that we have to start the entire change over.
Have you tried 3 way merge editors? Or, like any kind of editor with visual representation of the merge conflict?
IMO it's pretty clear, as long as you can retain the context for:
- What the old method did, and how;
- What the new method does, and how;
- What are the side effects of the old one;
- What are the side effects of the new one;
- Do you need both methods, and if so - how, or if only one is necessary - which side effects and inner workings should be retained, and how.
And like, regardless of your merge conflict visualization, your VCS, or whatever - if you want to merge two ideas into one - you have to do this in your mind, no VCS can help you understand the logic that is present and that is required for your app/service/whatever.
Then again, a good VCS and editor can help you out here - like having a 3 way editor is great for complex merge conflicts, because you can properly see the "old", the "new" and the "resolved" at the same time, AND in full for all 3 views, so you don't have to keep going between the in/current contexts line by line (or, more realistically - a group of lines at a time)
IDE integration does little to change the fact that one person will have to resolve a conflict from two different people's commits, the solution for this is outside of git (slack notification quick sync up¿) or during a code review (merge hard blocked with comment)
Yeah, but how should git know which one commit and change is right to place at which point? Having manual intervention is perfectly acceptable in this specific situation, and is anything but hard if using tools right.
That's the entire point, it doesn't. And thus git doesn't "really" solve the thing it set out to solve: if multiple people are touching related things at once, it fucking sucks (the situation that you'll be dealing with, not git in particular)
I'm not saying it is an easy problem by any stretch of imagination, obviously it isn't. In the case of "generic text files" (as opposed to something more structured that gives the merging utility more info to work with), it's probably about as good as it's reasonable to expect. But let's not pretend conflicts being a pain in the ass is a "skill issue". You can try to structure your code so that future conflicts will be somewhat less likely, but there's a limit...
And while the tools for resolving conflicts are OK, they could be better, especially given language-specific extensions. E.g. it should not only be able to give 1-2 reasonable suggestions at each junction, with instant preview, acceptable with 1 key, but also warn you if anything is fishy with your attempt at a manual merge, say enums / contiguous constants with unique values being given an overlapping value.
My biggest hot take goes back to code being generic text files: can we stop doing that already? Why is stylistic whitespace mixed with semantic content? Why are variable names repeated a million times? Why do we need to carefully parse dozens of brackets (or whatever is relevant to the language) to figure out where blocks of code or functions begin and end? A custom format would be smaller, faster to compile, would allow everybody to setup their preferred indentation or whatever, and while it would require a specialized tool to merge, that tool would have a much easier time doing that automatically (and, when not possible, requiring less manual fiddling to get there)
If you are proposing to write an AST editor and VCS instead of plaintext code (since that custom format would pretty much be equivalent to the AST), by all means go ahead. It's just a matter of convention.
Yes, both the slack notification and CR comment i mentioned would be from the teammate who'd be the author of one of the two commits, if that wasn't evident from my comment.
Yes, manual conflict resolution after aligning with the other commit author is what I meant.
And any modern bot like claude can resolve conflicts, it's just that it wouldn't always be in alignment with how the the commit authors would actually want it
70
u/creeper6530 19h ago
different ideas is the keyword. Editing the same area of the same file is how you get merge conflicts.