Elijah Newren <new...@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.
