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.

1.

  • Git: how to push changes made to only certain files?
  • git says everything-up-to-date when pushing changes to a remote branch
  • git cherry-pick -x default
  • Git: move changes between branches without working directory change
  • How to cherry-pick changes from one file to another file?
  • Git workflow and Gerrit
  • git checkout myBranch
    git cherry-pick begin..end
    

    or

    1. 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 --onto

    I tend to think that there shouldn’t be a difference. Am I mistaken?

  • Is there a “git touch” so I can push the same file with a new timestamp?
  • Create global pre-commit hooks for entire team
  • Is there a way to use wildcards with git checkout?
  • Android repo init - how to run non-interactively (or without name/email prompting)
  • Copy a git-push to another computer, or perform smaller incremental pushes?
  • Why remote git server should have --bare
  • 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.

    Git Baby is a git and github fan, let's start git clone.