Re: Cherry picking instead of merges.

[Linus Torvalds <torvalds@linux-foundation.org>]

On Thu, 3 Jul 2008, David Brown wrote:
> 
> First we tried a git-merge and resolved the conflicts.  The problem here is
> that the resultant code didn't work.  git-bisect wasn't very useful because
> the intermediate versions don't have resolved conflicts.
> 
> Yesterday, one developer cherry picked company B's changes into a branch.
> It appears he resolved the conflicts for each commit, which should make
> bisecting easier.

What I would suggest is actually a stupid combination of the two. The 
advantage and disadvantage of the cherry-picking is:

 - the cherry-picking obviously gave you the end result you wanted, and is 
   bisectable at a per-commit level (ie each cherry-pick was a 
   "micro-merge", and if there was a merge problem, it would show up 
   exactly in _that_ one)

BUT

 - the cherry-picking doesn't help future merges, since the history is 
   disjoint, and as such it will always diverge and just cause more and 
   more problems down the road to keep on doing this.

so what I would suggest is

 - generate the *state* of the tree by cherry-picking each commit one by 
   one, and verify that state.

 - but then do a merge that picks that one state as the merge result 
   (this is all assuming you cherry-picked every single commit, of 
   course!)

The latter thing is really easy to do. Just do the merge, and ignore the 
conflicts that happen entirely, because you then just use the tree from 
the temporary cherry-picking branch

	# Try to merge the other branch ..
	git merge otherbranch

	# .. but ignore conflicts entirely by then
	# setting the index and checked-out state to
	# the known-good end result
	git read-tree -u --reset cherry-picked-branch

	# .. and commit that instead
	git commit

	# and you can now remove the cherry-picked branch
	# that was only used for the tree
	git branch -D cherry-picked-branch

to actually commit that merge and get rid of the temporary cherry-picking 
branch.

(Of course, if the merge actually doesn't generate any conflicts, and thus 
commits it, but doesn't actually _work_, then that "git commit" needs to 
be a "git commit --amend" instead, in order to actually replace the merge 
commit rather than add a fixup commit afterwards)

End result: you have a nice merge with nice history that actually 
converges at a common point, but you effectively did the merge resolution 
one commit at a time with cherry-picking (or "git rebase", which is 
obviously just a convenient shorthand for cherry-picking everything).

This actually has a few other advantages too: "git show --cc" on that 
merge will also show the conflicts the way they got resolved, so you 
actually end up with some useful information this way too.

			Linus