Re: [PATCH v2 8/9] merge-recursive: enforce rule that index matches head before merging

[Junio C Hamano <gitster@pobox.com>]

Elijah Newren <newren@gmail.com> writes:

>     ...[merge will] abort if there are any changes registered in the index
>     relative to the `HEAD` commit.  (One exception is when the changed index
>     entries are in the state that would result from the merge already.)
>
> While this high-level description does describe conditions under which it
> would be safe to allow the index to diverge from HEAD, it does not match
> what is actually implemented.  In particular, unpack-trees.c has no
> knowledge of renames, and these two exceptions were written assuming that
> no renames take place.

I think the above analysis is quite correct (I even suspect that the
rule was outlined long before any renaming merge was designed).

> diff --git a/merge-recursive.c b/merge-recursive.c
> index 855ca39ca..8f7a8e828 100644
> --- a/merge-recursive.c
> +++ b/merge-recursive.c
> @@ -3257,6 +3257,13 @@ int merge_trees(struct merge_options *o,
>  		struct tree **result)
>  {
>  	int code, clean;
> +	struct strbuf sb = STRBUF_INIT;
> +
> +	if (!o->call_depth && index_has_changes(&the_index, head, &sb)) {
> +		err(o, _("Your local changes to the following files would be overwritten by merge:\n  %s"),
> +		    sb.buf);
> +		return -1;
> +	}

This change to ensure the index is pristine upfront makes sense,
too.