Re: merge-recursive: do not rudely die on binary merge

From: Chris Shoemaker <c.shoemaker@cox.net>
Date: Aug 14, 2007, 23:14 UTC
Message-ID: <20070814231422.GA10662@pe.Belkin>
In-Reply-To: <7v1we5bvbw.fsf@assigned-by-dhcp.cox.net>

On Tue, Aug 14, 2007 at 03:33:07PM -0700, Junio C Hamano wrote:

Show 11 quoted lines

> When you try to merge a path that involves binary file-level
> merge, merge-recursive died rudely without cleaning up its own
> mess.  A files added by the merge were left in the working tree,
> but the index was not written out (because it just punted and
> died), so it was cumbersome for the user to retry it by first
> running "git reset --hard".
> 
> This changes merge-recursive to still warn but do the "binary"
> merge for such a path; leave the "our" version in the working
> tree, but still keep the path unmerged so that the user can sort
> it out.

Very nice. Thanks, Junio. As an additional convenience, it would be nice to make the "theirs" version easily accessible. Perhaps, by leaving an untracked file in the working tree, with the original filename, suffixed with a hash-prefix. Or alternatively, cut-n-pastable instuctions on stdout for replacing the file with the "theirs" version.

On the other hand, I tend to think that "theirs" would be a better default than "ours" anyway - still leaving the path unmerged, of course.

-chris