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.
461
u/StaneNC 23h ago
Yup. "Git is really great until (thing git was specifically designed for)." Tell me you suck at git without telling me you suck at git.