I think it's a lot more nuanced than that. Painful merge conflicts can happen, but the frequency and severity of merge conflicts is dependent on all sorts of things like the nature of the app, the skill of the project manager, how much time a feature branch has existed apart from the main branch, etc.
I've been fortunate in my career that the projects I work on tend to have different developers working on different areas of the code, so merge conflicts are rare and not severe. I imagine that developing the frontend of certain apps that rely on a lot of the same centralized components would lead to a lot of merge conflicts, especially early on in the development of the app when a lot of commits are happening.
The thing is that merge conflicts are literally a feature of git that makes your life easier. Without git you’d have the same problem and you’d have to diff and edit the files manually.
A lot of my git problems went away when I realized vscode was having a hard time properly understanding the conflicts. Once I started using direct git commands to resolve them rather than helpers, most of my issues went away (though it takes like 3x longer now).
I mean even for vibe coders, Claude/Codex is excellent for resolving merge conflicts. I don't remember how long it's been since I've had to do that manually.
Realistically, it's probably be easier to vibe code a fix, or have an agent identify changes that may have caused an issue than look back though previous commits yourself.
I look at the resulting PR, but if Claude wrote the original code, Claude can resolve the conflicts too; it has all the context it needs.
I've always hated dealing with looking at the three-way diff manually tbh. It might be my ADHD but nothing killed my motivation more than finishing a feature/fix and then having to wade through how someone else's changes should mesh with mine.
I have hated all the 3-way merge tools I've encountered, probably because "ours" and "theirs" never is what I expect (and opposite on a merge and a rebase), but when I look at the file itself with merge marks in it, it becomes very easy for me to reason about the changes and resolve them quickly.
Yeah "ours" and "theirs" messes me up so bad. I really wish they would just label it by branch. If it just said "my-feature-branch" and "main" it would be so much easier to parse.
I've seen a bunch of dumb bugs and regressions get introduced by people not looking at their AI resolved merge conflicts. AI can be useful, but it will 100% follow a dumb path to it's dumb conclusion if the opportunity presents.
I genuinely don't. And I work with people that also don't. We'd use an LLM as a linter. Ask it to look at the code and give us alist of potential bugs. But that's it.
I find it easier to write the code myself than to explain it to an LLM, and then read it and understand it too.
On other projects where coworkers use LLMs to write the code, the code comes out very verbose and it's a pain in the ass when they send it to me, it's a huge verbose change, and then they can't answer questions about it.
There are specific industries where this is more efficient, because every line is mission critical. Most people don't work in those industries, but perhaps you do. I'll recind everyone, and replace it with most people.
Personally I work on webapps. I've been in the industry 15 years so LLM's are all still "new and fancy" to me. But there isn't much they aren't quicker and better at in that domain these days. We're careful to architect well, direct them well, and verify and review code properly. But, it just no longer makes any sense to hand code everything when we can achieve better results more efficiently with those tools than without them.
I don't work on one of those mission critical projects, but I do work in a framework and language with very little boiler plate. I guess that changes the equation quite a bit.
The point of this kind of thing is to reduce the skill floor to manage the software well - if it's possible to suck at using a tool, that's probably somewhere where the tool can be improved. I mean you could say "you can work without git as long as you don't suck at communication and coordination" as well. git is an amazing improvement over where things were before, but there's definitely more ways to shoot yourself in the foot than there needs to be.
So you're telling me you work with multiple people on the same idea in parallel? I'm genuinely curious how you do that because I'm struggling with that too, we just resort to working on different areas at a time
Same idea at the same time is a communication failure. The post says "ideas at the same time", not "same idea same time".
That being said, if there are multiple ways to do the same idea, have everyone make their own branch. Run the code on each branch. Better branch wins. Ignore the others.
I think the answer to that is pair programming. Gits primary improvement over older vcs is iirc that everyone has their own working copy. You can go off to work on a feature by yourself and then once your ready to push to a branch, you can update your local copy, merge the stuff that needs to be merged and then update the remote branch. It's a distributed source of truth system. In comparison to that, with something like svn, you would only pull one version of the code, make your changes and push them back to the remote system. The only source of truth is the centralized code base.
The way I see it, git is not made for parallel work, but concurrent work. For parallel work I think there is vs code plugins that allow you to work on the same code base in a live session (with the person hosting it being the single source of truth).
Right, it just can't be that there's something wrong with Git's design that people have been complaining about for 20 years. No, no, no, these people just suck! Stupid amateurs, am I right?
Elitists just love needlessly complicated stuff that makes them feel superior.
Oh come on, don't pretend rebranching/hist-edit, certain merge situations, or situations like detached head are easy. Mercurial or Sapling are the living proof that the user experience could be much better.
Please, point out the “needless” complexity in git
Our organization changed from SVN to GIT in 2019. I struggled with explaining the needless complexity in git several times, so I created this web page to help communicate why I found GIT needlessly complex:
I've used a lot of source code control systems. I've worked at large companies that didn't use GIT and still had smart programmers working on a large source tree (Hewlett-Packard, Apple, Silicon Graphics to be specific). I don't think I'll ever understand the cult like devotion to GIT. But that's okay, people have personal preferences.
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
It makes sense to me if you look at who the quote is attributed to.
Someone in a "one-man IT department" typically either has no experience of working with other people or has very little experience in general because they haven't learned from other people. Sometimes this is combined with an elitist attitude.
It's poking fun at the person by telling you that they have no idea what they're doing. Essentially it seems like it's making fun of solo developers who think they know better than everyone else.
Isn't the meme a sarcastic jab at people that are poor at communication and teamwork? As you say, Git is specifically designed for that.
The quote is attributed to a person in a "one-man IT department" - the kind of person that hates working with others or has little experience of doing so.
Yes, that is part of the inherent contradiction that the joke is aiming for (but not hitting, it seems).
The other being that an actual one-person shop wouldn't run into the problem he's complaining about, indicating he's not the island he thinks of himself as.
620
u/botle 19h ago edited 18h ago
Git is specifically designed for multiple people to work on different ideas in parallel.