Does picking a range of commits with cherry-pick or rebase –onto end up with the same result?
I sometimes want to pick a range of commits from a different repository. I know two ways to do that.
- git rebase: “error: cannot stat 'file': Permission denied”
- How git-merge and git-rebase behave with a topic branch forked off of another topic branch?
- Why do I get conflicts with git rebase -p -i?
- Rebase-push cycles for git branches
- How do merge and rebase work?
- Rebase all branches without switching to them
git checkout myBranch git cherry-pick begin..end
git rebase --onto myBranch begin end
I find the first version easier to remember. However, I read a lot about how cherry-picking is evil compared to merging because it kinda breaks the history. But what I haven’t figured out yet is if there is a difference between cherry-picking a range of commits or rebasing them with
I tend to think that there shouldn’t be a difference. Am I mistaken?
3 Solutions collect form web for “Does picking a range of commits with cherry-pick or rebase –onto end up with the same result?”
These two commands are equivalent, you’re just doing the work that a normal rebase would do to figure out the unmerged commits to replay onto the target branch.
Rebasing and cherry-picking are just as ‘bad’ for merges. They both result in forgetting the IDs of the original commits for the changes you pick up; as a result, later merges may attempt to apply the same changes more than once.
Actually, cherry-picking is less evil in this respect than rebasing. Cherry picking will create duplicates of commits, while rebasing will actually move them (thus rewriting history).
Both are more evil then merging, which in my honest opinion is usually the worst choice.