Re: [PATCH 6/8] apply: fall back on three-way merge
- From
Jeff King <peff@peff.net>
- Date
- May 10, 2012, 20:31 UTC
- 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:
Show 13 quoted lines
> +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