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

Programmer Humor

19551 readers
970 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
Feyter@programming.dev
anzo@programming.dev
BurningTurtle@programming.dev
pylapp@programming.dev
1114
Rebase Supremacy (programming.dev)
submitted 7 months ago by JPDev@programming.dev to c/programmer_humor@programming.dev
238 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] 13@kbin.run 66 points 7 months ago* (last edited 7 months ago) (3 children)

Imagine rewring history

[–] wise_pancake@lemmy.ca 86 points 7 months ago

History is written by the squashers.

[–] magic_lobster_party@kbin.run 23 points 7 months ago (1 children)

Imagine working with a tangled spaghetti of history

[–] victorz@lemmy.world 11 points 7 months ago

You don't? Just follow the merges.

[–] muad_dibber@lemmygrad.ml 5 points 7 months ago (2 children)

You try to pull someone's changes, but whoops, they used rebase and rewrote history! Delete the branch and start over.

[–] thesmokingman@programming.dev 9 points 7 months ago (1 children)

No you just do a rebase to bring it in. Assuming you’re making atomic commits you shouldn’t have a ton of merge conflicts. If you have to do this a lot, your branch scope is really bad and the problem isn’t in how you’re using got, it’s in how you’re slicing work.

[–] muad_dibber@lemmygrad.ml 4 points 7 months ago (1 children)

If you try to pull someone else's rebased / history rewritten branch, your git will tell you that it's rejected. You can completely avoid this by merging instead of rewriting history.

[–] Atemu@lemmy.ml 1 points 7 months ago

...or you simply rebase the subset of commits of your branch onto the rewritten branch. That's like 10 simple button presses in magit.

[–] expr@programming.dev 3 points 7 months ago* (last edited 7 months ago)

2 things:

  1. You don't pull rebased work pretty much ever. Rebasing is for feature branches by a single author to craft a high quality history, generally. It's much, much better than littering your branch with merge commits from upstream.
  2. If for some reason you do need to pull rebased changes, you simply do git pull --rebase. Works without issue.