this post was submitted on 04 Apr 2024
1113 points (98.1% liked)

Programmer Humor

19589 readers
2179 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 1 year ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 51 points 7 months ago* (last edited 7 months ago) (26 children)

I prefer to rebase as well. But when you're working with a team of amateurs who don't know how to use a VCS properly and never update their branc with the parent branch, you end up with lots of conflicts.

I find that for managing conflicts, rebase is very difficult as you have to resolve conflicts for every commit. You can either use rerere to repeat the conflict resolution automatically, or you can squash everything. But when you're dealing with a team of Git-illiterate developers (which is VERY often the case) you can either spend the time to educate them and still risk having problems because they don't give a shit, or you can just do a regular merge and go on with your life.

Those are my two cents, speaking from experience.

[–] [email protected] 18 points 7 months ago (18 children)

I agree that merge is the easier strategy with amateurs. By amateurs I mean those who cannot be bothered to learn about rebase. But what you really lose there is a nice commit history. It's good to have, even if your primary strategy is merging. And people tend to create horrendous commit histories when they don't know how to edit them.

[–] [email protected] 4 points 7 months ago (2 children)

Why would you want to edit your commit history? When I need to look at it for some reason, I want to see what actually happened, not a fictional story.

[–] [email protected] 2 points 7 months ago

Because when debugging, you typically don't care about the details of wip, some more stuff, Merge remote-tracking branch 'origin/master', almost working, Merge remote-tracking branch 'origin/master', fix some tests etc. and would rather follow logical steps being taken in order with descriptive messages such as component: refactor xyz in preparation for feature, component: add do_foo(), component: implement feature using do_foo() etc.

load more comments (1 replies)
load more comments (16 replies)
load more comments (23 replies)