From: Jeff King <peff@peff.net>
Date: Thu, 10 May 2012 20:31:13 GMT
Subject: Re: [PATCH 6/8] apply: fall back on three-way merge
Message-ID: <20120510203113.GB18276@sigill.intra.peff.net>
In-Reply-To: <1336629745-22436-7-git-send-email-gitster@pobox.com>

On Wed, May 09, 2012 at 11:02:23PM -0700, Junio C Hamano wrote:

> +static int try_threeway_fallback(struct image *image, struct patch *patch,
> +				 struct stat *st, struct cache_entry *ce)
> +{
> +	unsigned char pre_sha1[20], post_sha1[20], our_sha1[20];
> +	struct strbuf buf = STRBUF_INIT;
> +	size_t len;
> +	char *img;
> +	struct image tmp_image;
> +
> +	/* No point falling back to 3-way merge in these cases */
> +	if (patch->is_binary || patch->is_new || patch->is_delete ||
> +	    S_ISGITLINK(patch->old_mode) || S_ISGITLINK(patch->new_mode))
> +		return -1;

Is it true that there is no point in doing a 3-way fallback when
patch->is_binary? What if the user has a custom merge driver?
For that matter, a custom driver could handle additions or deletions,
too (e.g., for a sorted record-oriented file, merging two additions
might just mean collating the records).

It seems like we should just keep the logic here as stupid as possible,
try to setup the 3-way content, and then hand it off to the merge code
to try to make something happen. The only thing we have to lose is a
little bit of efficiency in setting up blobs that are unlikely to
actually get merged.

-Peff