▲ 472 ▼ History repeats itself (lemmy.world) submitted 3 years ago by alphacyberranger@lemmy.world to c/programmer_humor@programming.dev 35 comments fedilink hide all child comments
[–] yogo@lemm.ee 10 points 3 years ago (2 children) That’s called rebasing permalink fedilink source parent hideshow 4 child comments replies: [–] atyaz@reddthat.com 5 points 3 years ago (1 child) 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. permalink fedilink source parent hideshow 2 child comments replies: [–] yogo@lemm.ee 9 points 3 years ago* (last edited 3 years ago) (1 child) 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 permalink fedilink source parent hideshow 2 child comments replies: [–] atyaz@reddthat.com 1 point 3 years ago (1 child) "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. permalink fedilink source parent hideshow 2 child comments replies: [–] yogo@lemm.ee 2 points 2 years 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 permalink fedilink source parent [–] fiah@discuss.tchncs.de 4 points 3 years ago* (1 child) for some reason it's easier than normal rebasing though permalink fedilink source parent hideshow 2 child comments replies: [–] yogo@lemm.ee 3 points 3 years ago (1 child) Have you tried interactive rebase (rebase -i)? I find it very useful permalink fedilink source parent hideshow 2 child comments replies: [–] Blamemeta@lemm.ee 0 points 3 years ago (2 children) Yeah, but then you deal with merge conflicts permalink fedilink source parent hideshow 4 child comments replies: [–] dukk@programming.dev 2 points 2 years ago You can get merge conflicts in cherry picks too, it’s the same process. permalink fedilink source parent [–] gedhrel@lemmy.ml 2 points 3 years 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.) permalink fedilink source parent
[–] atyaz@reddthat.com 5 points 3 years ago (1 child) 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. permalink fedilink source parent hideshow 2 child comments replies: [–] yogo@lemm.ee 9 points 3 years ago* (last edited 3 years ago) (1 child) 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 permalink fedilink source parent hideshow 2 child comments replies: [–] atyaz@reddthat.com 1 point 3 years ago (1 child) "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. permalink fedilink source parent hideshow 2 child comments replies: [–] yogo@lemm.ee 2 points 2 years 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 permalink fedilink source parent
[–] yogo@lemm.ee 9 points 3 years ago* (last edited 3 years ago) (1 child) 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 permalink fedilink source parent hideshow 2 child comments replies: [–] atyaz@reddthat.com 1 point 3 years ago (1 child) "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. permalink fedilink source parent hideshow 2 child comments replies: [–] yogo@lemm.ee 2 points 2 years 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 permalink fedilink source parent
[–] atyaz@reddthat.com 1 point 3 years ago (1 child) "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. permalink fedilink source parent hideshow 2 child comments replies: [–] yogo@lemm.ee 2 points 2 years 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 permalink fedilink source parent
[–] yogo@lemm.ee 2 points 2 years 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 permalink fedilink source parent
[–] fiah@discuss.tchncs.de 4 points 3 years ago* (1 child) for some reason it's easier than normal rebasing though permalink fedilink source parent hideshow 2 child comments replies: [–] yogo@lemm.ee 3 points 3 years ago (1 child) Have you tried interactive rebase (rebase -i)? I find it very useful permalink fedilink source parent hideshow 2 child comments replies: [–] Blamemeta@lemm.ee 0 points 3 years ago (2 children) Yeah, but then you deal with merge conflicts permalink fedilink source parent hideshow 4 child comments replies: [–] dukk@programming.dev 2 points 2 years ago You can get merge conflicts in cherry picks too, it’s the same process. permalink fedilink source parent [–] gedhrel@lemmy.ml 2 points 3 years 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.) permalink fedilink source parent
[–] yogo@lemm.ee 3 points 3 years ago (1 child) Have you tried interactive rebase (rebase -i)? I find it very useful permalink fedilink source parent hideshow 2 child comments replies: [–] Blamemeta@lemm.ee 0 points 3 years ago (2 children) Yeah, but then you deal with merge conflicts permalink fedilink source parent hideshow 4 child comments replies: [–] dukk@programming.dev 2 points 2 years ago You can get merge conflicts in cherry picks too, it’s the same process. permalink fedilink source parent [–] gedhrel@lemmy.ml 2 points 3 years 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.) permalink fedilink source parent
[–] Blamemeta@lemm.ee 0 points 3 years ago (2 children) Yeah, but then you deal with merge conflicts permalink fedilink source parent hideshow 4 child comments replies: [–] dukk@programming.dev 2 points 2 years ago You can get merge conflicts in cherry picks too, it’s the same process. permalink fedilink source parent [–] gedhrel@lemmy.ml 2 points 3 years 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.) permalink fedilink source parent
[–] dukk@programming.dev 2 points 2 years ago You can get merge conflicts in cherry picks too, it’s the same process. permalink fedilink source parent
[–] gedhrel@lemmy.ml 2 points 3 years 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.) permalink fedilink source parent
