When using version control and working on a branch other than the master, one should periodically pull any changes made to master into the working branch. If you are using Git, the preferred way to do this is with the rebase command rather than merge. (Here is a good explanation of the difference between the two and why rebase is usually preferred.)

However, rebase sometimes does not work as you would like. I hit a good example of this this evening and wanted to document it. The scenario is that of working on my own working branch of a rails project where we had just started using RubyMine. I had created my working branch just prior to switching to RubyMine. To my chagrin, I discovered that RubyMine had created a bunch of files to manage its view of the project in a folder named .idea, and I had committed them in my branch.

In the meantime another developer discovered the same issue and coincidentally added the .idea directory to .gitignore on master. The natural thing to do, I thought, was to rebase my branch on master. I was promptly told that I could not do this. I failed to capture the exact error message, but basically the problem was that rebase was attempting to replay the addition of files to the .idea directory on top of a git repository that now called for the .idea directory to be ignored.

Because I only had a few commits on my branch, I decided the quick solution would be to create a new working branch based on the current master and then cherry-pick my commits from the old working branch onto the new one.

My first cherry-pick command resulted in a “commit not found error.” I thought this was very odd, but in examining the contents of the commit I was attempting to cherry-pick, it turns out that it only contained files in the .idea directory. So it seems a better error message would have been “nothing found in the commit.”

Seeing as I could safely omit that commit, I went on to cherry-pick the remaining ones. Each failed initially due to merge errors, because each attempted to modify files under .idea. To solve this I had to execute a git rm -f <file> command for each such file to resolve the conflict.

After resolving the conflict, I followed the onscreen instructions that were given at the point that the cherry-pick failed. Namely to run the commit -c <hash> command specifying the hash of the commit I had cherry-picked.

The -c option creates a new commit with the same message and author as the one referenced by the hash. I had not seen this option before and as it turns out I really wanted to use the capitalized -C version. Both do the same thing but the lowercase version throws you into vi to edit the commit message where as the uppercase one uses the commit message as-is.