Tonfa is right. What you’re describing isn’t ‘merging’ (or ‘pushing’ or ‘pulling’); it’s ‘cherry-picking’. A push or a pull moves all the changesets from one repo to another that aren’t already in that repo. A ‘merge’ takes two ‘heads’ and merges them down to a new changeset that’s the combination of both. If you really … Read more
Next time try git cherry-pick –abort, otherwise what you did should more or less work.
A git SHA hash is computed from different pieces of information: The tree it refers to; basically, the current content of the repository in the branch in which the commit appears. The SHA of the parent commit(s). The commit message. The author information: name, email and timestamp. The committer information: name, email and timestamp. Even … Read more
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
When you update to D and graft F::J, Mercurial runs a number of merges. It will start with this merge: M = three_way_merge(local=D, other=F, base=E) If we write +d for the delta between the states C and D, then we start with: +d +e +f —- C —- D —- E —- F —- Turn … 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
Short answer Don’t worry, Git will handle it. Long answer Unlike e.g. SVN1, Git does not store commits in delta format, but is snapshot-based2,3. While SVN would naively try to apply each merged commit as a patch (and fail, for the exact reason you described), Git is generally able to handle this scenario. When merging, … Read more
When you cherry-pick, it creates a new commit with a new SHA. If you do: git cherry-pick -x <sha> then at least you’ll get the commit message from the original commit appended to your new commit, along with the original SHA, which is very useful for tracking cherry-picks.
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 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