3 ms·
Not who you're responding to, but I also understand merge more readily than rebase. Your explanation doesn't really help. Applying a commit "on another branch
by recursive 3y ago
Not who you're responding to, but I also understand merge more readily than rebase. Your explanation doesn't really help.
Applying a commit "on another branch" isn't really well defined in my mind. In my understanding, a commit consists of one or more parent commits, and the complete state of a tree, including the entire contents of all the files in it.
Maybe there are other ways to be confused, but all of the uncertainty has been shoved into that simple phrase "apply a commit on another branch". What does that actually mean?
- dale_glass 3y ago> "apply a commit on another branch". What does that actually mean? Calculate the difference between the commit and its parent, and repeat that change against another branch. So, like git log of your work over 10 days, git show each commit individually, then apply each patch that generates against the latest code.
- pertymcpert 3y agoOf course it's defined, even git knows what it means because that's what cherry-pick does.
- recursive 3y agoSo cherry-pick is actually merge, and rebase is actually cherry-pick? Everything is merge.
- pertymcpert 3y agoNo, cherry-pick is cherry-pick. Rebase is a composite action which includes one or more cherry-picks.
- ecnahc515 3y agoHave you ever used git cherry-pick? Git rebase is if you were loop over each commit (bottom to top) and run `git cherry-pick` on each commit separately. If you haven't used git cherry-pick, then it is basically a shortcut for `git show $REF | git apply -`, where the short cut is the simplest form of using git, you have a patch (via git show) and you want to apply it to your local checkout.