Comment on History repeats itself

• 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.

  source

  • 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

    source

    • 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.

      source

      • yogo@lemm.ee ⁨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
        

        source
• fiah@discuss.tchncs.de ⁨1⁩ ⁨year⁩ ago

  for some reason it’s easier though

  source

  • yogo@lemm.ee ⁨1⁩ ⁨year⁩ ago

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

    source

    • Blamemeta@lemm.ee ⁨1⁩ ⁨year⁩ ago

      Yeah, but then you deal with merge conflicts

      source

      • dukk@programming.dev ⁨1⁩ ⁨year⁩ ago

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

        source