I’ve definitely done this before…
Comment on History repeats itself
Blamemeta@lemm.ee 1 year agoWhat 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.
BabaYaga@reddthat.com 1 year ago
GigglyBobble@kbin.social 1 year ago
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 year ago
Git is weird sometimes.
JDubbleu@programming.dev 1 year ago
This is actually genius. Gonna start using this at work.
yogo@lemm.ee 1 year ago
That’s called rebasing
atyaz@reddthat.com 1 year ago
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 1 year ago
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 apply 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. git-scm.com/docs/git-rebase
atyaz@reddthat.com 1 year ago
“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.
fiah@discuss.tchncs.de 1 year ago
for some reason it’s easier though
yogo@lemm.ee 1 year ago
Have you tried interactive rebase (rebase -i)? I find it very useful
Blamemeta@lemm.ee 1 year ago
Yeah, but then you deal with merge conflicts