this post was submitted on 28 Aug 2024
524 points (97.1% liked)

Programmer Humor

32561 readers
421 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 5 years ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] dohpaz42@lemmy.world 53 points 2 months ago (2 children)

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.

[–] dfyx@lemmy.helios42.de 37 points 2 months ago* (last edited 2 months ago)

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.

[–] PotatoesFall@discuss.tchncs.de 4 points 2 months ago (1 children)

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

[–] dohpaz42@lemmy.world 4 points 2 months ago (1 children)

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 --rebase is 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.

[–] PotatoesFall@discuss.tchncs.de 2 points 2 months ago (1 children)

not scary at all

I have seen some juniors really shoot themselves in the foot with rebasing, and I've been there as well before. I agree it can be useful, but it definitely requires understanding of what is going on :P

[–] dohpaz42@lemmy.world 3 points 2 months ago

What I suggest is not the same as using git rebase. It’s pretty automatic and easily abortable.