Git is duplicating code

Question

We just switched from Subversion to Git.

The problem that came up this morning was that we cherry-picked a commit from a branch into master so maser would have a bug fix. Then we merged master back to the branch.

When we tried to compile, all of the additions from the cherry-picked commit were in the code twice.

The cherry-picked commit consisted of the addition of a couple of lines of code, which ended up afterward being in the code twice. Luckily they were entire functions so it threw a compiler error.

There was never a conflict raised.

How do we avoid this. It's a major problem.

Thanks.

Answer 1

A cherry-pick is a different commit from Git's point of view. i.e. when you merge back, you're merging back a new commit on top of that originally applied.

That is to say, you create a commit with hash ABC. You cherry-pick it across, creating a new commit DEF. The merge back then applies DEF alongside ABC.

In the above, I would perhaps expect you to simply perform the commit on master (say) and cherry-pick that to your branch.

This blog post has more info.

Notice that it creates a new commit on the master branch. If, on master, you run "git log", you'll see a different hash for the same commit message. Why?

This is because of how Git models what a commit is. A commit is a complete snapshot of the whole repository, and the hash for a given commit reflects the state of every file in the whole directory - it is a hash of all their hashes.

So clearly, since master branch doesn't have all of the commits from the feature branch, a complete snapshot of it at the time the bugfix is applied will generate a different hash than a complete snapshot of the feature branch at the time the bugfix is applied there. Thus, different hashes.

But when you do merge the feature branch into master, that won't matter; the hashes for the individual file where you made the bugfix will be the same, because their contents will be the same, so there will be nothing to update on master for that file.

This blog post details a similar situation and how to use git rebase to avoid such issues.