this post was submitted on 14 Aug 2023
464 points (97.7% liked)

Programmer Humor

19551 readers
950 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
[–] Blamemeta@lemm.ee 8 points 1 year ago (4 children)

What you do is create a third branch off master, cherry pick the commits from the feature branch, and merge in the third branch. So much easier.

[–] yogo@lemm.ee 8 points 1 year ago (2 children)
[–] atyaz@reddthat.com 5 points 1 year ago (1 children)

That is absolutely not what rebasing does. Rebasing rewrites the commit history, cherry picking commits then doing a normal merge does not rewrite any history.

[–] yogo@lemm.ee 8 points 1 year ago* (last edited 1 year ago) (1 children)

I’m sorry but that’s incorrect. “Rewriting the commit history” is not possible in git, since commits are immutable. What rebase actually does is reapply each commit between upstream and head on top of upstream, and then reset the current branch to the last commit applied (This is by default, assuming no interactive rebase and other advanced uses). But don’t take my word for it, just read the manual. https://git-scm.com/docs/git-rebase

[–] atyaz@reddthat.com 1 points 1 year ago (1 children)

"Reapply" is rewriting it on the other branch. The branch you are rebasing to now has a one or multiple commits that do not represent real history. Only the very last commit on the branch is actually what the user rebasing has on their computer.

[–] yogo@lemm.ee 2 points 1 year ago

Cherry picking also rewrites the commits. This is equivalent to rebasing:

git branch -f orig_head
git reset target
git cherry-pick ..orig_head
[–] fiah@discuss.tchncs.de 4 points 1 year ago* (last edited 1 year ago) (1 children)

for some reason it's easier than normal rebasing though

[–] yogo@lemm.ee 3 points 1 year ago (1 children)

Have you tried interactive rebase (rebase -i)? I find it very useful

[–] Blamemeta@lemm.ee 0 points 1 year ago (2 children)

Yeah, but then you deal with merge conflicts

[–] dukk@programming.dev 2 points 1 year ago

You can get merge conflicts in cherry picks too, it’s the same process.

[–] gedhrel@lemmy.ml 2 points 1 year ago

rerere is a lifesaver here.

(I'm also a fan of rebasing; but I also like to land commits that perform a logical and separable chunk of work, because I like history to have decent narrative flow.)

[–] GigglyBobble@kbin.social 3 points 1 year ago (1 children)

If your cherry-pick doesn't run into conflicts why would your merge? You don't need to merge to master until you're done but you should merge from master to your feature branch regularly to keep it updated.

[–] Blamemeta@lemm.ee -1 points 1 year ago

Git is weird sometimes.

[–] BabaYaga@reddthat.com 3 points 1 year ago

I’ve definitely done this before…

[–] JDubbleu@programming.dev 2 points 1 year ago

This is actually genius. Gonna start using this at work.