You have to supply -m if the commit is a merge commit, i.e. a commit with more than one parent. Normally, what git cherry-pick REV does can be described as: Take the changes between rev and its parent. Apply these changes to the current HEAD and commit the result with rev‘s commit message. A merge … Read more
The answer, as given, is to use format-patch but since the question was how to cherry-pick from another folder, here is a piece of code to do just that: $ git –git-dir=../<some_other_repo>/.git \ format-patch -k -1 –stdout <commit SHA> | \ git am -3 -k Explanation from Cong Ma comment Aug 28 ’14 git format-patch … Read more
The most troubling feature new developers to DVCS need to realize is about the publication process: you can import (fetch/pull) whatever remote repo you need you can publish (push) to any (bare) repo you want From that, you can respect a few rules to make your questions easier: only rebase a branch if it hasn’t … Read more
Git is resolving the cherry-pick as a no-op — all of the changes introduced by that commit have been introduced by some commit on your current branch. (Or that’s what Git thinks, anyway.) Verify that the commit you are cherry-picking hasn’t already been merged somehow, as either a proper merge, rebase/cherry-pick, or piecemeal patch. (Use … Read more
Both rebase (and cherry-pick) and merge have their advantages and disadvantages. I argue for merge here, but it’s worth understanding both. (Look here for an alternate, well-argued answer enumerating cases where rebase is preferred.) merge is preferred over cherry-pick and rebase for a couple of reasons. Robustness. The SHA1 identifier of a commit identifies it … Read more
The way a cherry-pick works is by taking the diff a changeset represents (the difference between the working tree at that point and the working tree of its parent), and applying it to your current branch. So, if a commit has two or more parents, it also represents two or more diffs – which one … Read more
I’d do it with cherry-pick -n (–no-commit) which lets you inspect (and modify) the result before committing: git cherry-pick -n <commit> # unstage modifications you don’t want to keep, and remove the # modifications from the work tree as well. # this does work recursively! git checkout HEAD <path> # commit; the message will have … Read more
There are four ways of doing so: Clean way, reverting but keep in log the revert: git revert –strategy resolve <commit> Harsh way, remove altogether only the last commit: git reset –soft “HEAD^” Note: Avoid git reset –hard as it will also discard all changes in files since the last commit. If –soft does not … Read more
The “avoiding duplicate commit” article mentioned in tonio’s answer says: Imagine we have the master branch and a branch b: o—X <– master \ b1—b2—b3—b4 <– b Now we urgently need the commits b1 and b3 in master, but not the remaining commits in b. So what we do is checkout the master branch and … Read more
Git 1.7.2 introduced the ability to cherry pick a range of commits. From the release notes: git cherry-pick learned to pick a range of commits (e.g. cherry-pick A..B and cherry-pick –stdin), so did git revert; these do not support the nicer sequencing control rebase [-i] has, though. To cherry-pick all the commits from commit A … Read more