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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html