Re: cherry picking and merge

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Aug 1, 2014, 02:43 UTC
Message-ID: <20140801024329.GA28914@vauxhall.crustytoothpaste.net>
In-Reply-To: <51C01AAA-3CFB-4110-BAE9-7D04CA8EE53A@comcast.net>

On Thu, Jul 31, 2014 at 05:58:17PM -0700, Mike Stump wrote:

Show 21 quoted lines

> Cherry picking doesn’t work as well as it should.  I was testing on
> git version 1.7.9.5.
> 
> Put in a line in a file, call it:
> 
> first version
> 
> then cherry pick this into your branch. Then update on master and transform that into:
> 
> second version
> 
> then, merge that branch back to master.  Death in the form of conflicts.
> 
> In gcc land, I do this sort of thing all the time, and I need a
> merging subsystem to actually keep track of things.  I can manage this
> will diff and patch and it works flawlessly.  The point of using
> something better than diff and patch is for it to be better than diff
> and patch.
> 
> I’d like for merge to merge in the work that has yet to be merged.
> Not that, plus blindly try and apply or reapply cherry picked items.

You're not the first person to be surprised by the way merge works. From the git-merge manpage:

  [This behavior] occurs because only the heads and the merge base are
  considered when performing a merge, not the individual commits.

(That was added after 1.7.9.5.)

If you want the behavior of applying multiple patches in a row, you want to use git rebase, not git merge. Since rebase re-applies the patches of each of your commits on top of another branch, the identical change won't cause conflicts.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187