Re: [PATCH v2 8/9] merge-recursive: enforce rule that index matches head before merging
From: Junio C Hamano <hidden>
Date: 2018-07-03 20:07:45
Elijah Newren [off-list ref] 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).
quoted hunk
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.