Programmer Humor

32759 readers

665 users here now

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

Rules:

Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.

founded 5 years ago

MODERATORS

AgreeableLandscape@lemmy.ml

cat_programmer@lemmy.ml

528

It happens each time! (lemmy.world)

submitted 4 months ago by n3cr0@lemmy.world to c/programmerhumor@lemmy.ml

55 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] sushibowl@feddit.nl 3 points 4 months ago (2 children)

The reason for this is that git rebase is kind of like executing a separate merge for every commit that is being reapplied. A proper merge on the other hand looks at the tips of the two branches and thus considers all the commits/changes "at once."

You can improve the situation with git rerere

[–] cyborganism@lemmy.ca 2 points 4 months ago

Holy shit! I never took the time to read about it rerere. But it all makes sense now.

However, it's still a lot of extra steps for what could otherwise be really simple with a regular merge.

Is there really a big advantage in using rebase vs merge other than trying to keep a single line of progress in the history? It's it really worth all the hassle? Especially if you're using a squash merge in a pull request...

[–] zalgotext@sh.itjust.works 1 points 4 months ago

I don't think rerere applies here. Once you do a rebase, the rewritten commits should contain the conflict resolutions. The only way conflicts could reoccur on subsequent rebases is if changes reoccur in those same files/lines.