I know this is a joke, but those errors/warnings/messages screenshot is not from git. That looks more like results from a compiler of some sort.
Looks exactly like Visual Studio 2022.
I guess the joke implies that automated (or incorrect manual) conflict resolution causes code that doesn't compile. But still not git's fault. They should probably have merged earlier and in rare cases where that wasn't possible, you have to bite the bullet and fix this stuff.
When people do a bunch of bulk renames on every commit, then you get this kind of problem a lot. But yeah still not gits fault
In my experience, this amount of conflicts typically occurs because 1) most people mass commit a bunch of (mostly unrelated) changes at once, which leads to 2) inexperienced/impatient devs to clobber incoming merge conflicts without doing proper merges (mostly because they can’t make heads or tails of the diffs).
This is very easily mitigated if all developers would make small, related commits (with descriptive commit messages and not “committing changes”). This makes everybody’s life easier because 1) diffs are smaller and readable for conflicts, 2) the dev can see the progression of code through commit history, 3) broken code is more easily revertable (and traceable) if something goes wrong, and 4) it’s easier to cherry pick specific changes if the whole changes cannot be published all at once.
Also,
git pull --rebaseis your friend and not scary at all. It applies all incoming changes first, then applies your new commits last. 9 out of 10 times it avoids conflicts.Lastly, use a GUI. There are plenty out there to suit your tastes, and I feel they are a safer and easier alternative than CLI. Some GUIs are very safe and even allow undo operations on most things.
Sometimes I look at the memes around here and wonder wtf y'all are doing. Like, neither my code nor the code at the place I work at are perfect. But I don't think I've ever seen a merge do this. Maybe some of the most diverged merges temporarily had a lot of errors because of some refactoring, but then it was just a few find + replaces away from being fixed again. But those were merges where multiple teams had been working on both the original and the fork for years and even then it was usually pretty okay.
You need to merge more often.
Rebase. That's where the real trauma is.
Neither rebasing nor merging should cause trauma if everyone on the team takes a day or two to understand git
I consider myself above average in terms of Git know how. But I've come across situations using rebase where you're stuck resolving the same conflicts over several commits.
I still don't understand that part quite well.
This doesn't happen when you do a normal merge though. Making it easier to manage
And the branch should be alive a shorter period
Absolutely
To be fair, this is also how VS looks when you open a project fresh from the clone. Or after updating .net versions. .NET is awful about losing references and then claiming thousands of errors. Sometimes just running the build will fix it by relinking the DLLs it couldn't find.
But also yes, VS with a team can be "fun" if people don't sync their formatting settings. I once had a junior that kept converting spaces to tabs on every file he'd touch. You'd get it fixed and then he'd screw up his settings again with a VS update or something.
POV: Your codebase undergoes a full refactor for every feature
My codebase doesn't have features, I've been refactoring hello world for 25 years.
ALL KINDS OF SUFFERING ARE MERGE CONFLICTS
GIT IS OUR MIRROR
REBASE IS HEAVEN
oof.wav
I suck at git.
I'm currently rebasing 17k commits into my branch. I'm letting it run overnight.I'm disgusting.
Jokes on merge.. when a rebase editing goes wrong after +15 commits and six hours, and git hits you with a leadpipe: "do it. Do it again, or reassemble your branch from the reflog." I.e. you commited a change very early, went over bunch of commits resolving/fixing/improving them and at middle way forget if you should
commit --amendorrebase --continueto move forward. Choose wrong, and two large change-sets get irreversilbly squashed together (that absolutely shouldn't), with no way to undo. Cheers. 👍Narrator: But it could, in fact, hurt him...
I literally make a new branch. clone, and use an external merge tool (beyond compare) when my branch has fallen too far behind. I don't trust any of the automated processes.
If I saw this in my code… I’d just… I’d have a mental breakdown
rerere makes resolving these almost bearable
Git flow eliminated 95% of merging issues for my team
