Re: [PATCH v2 8/9] merge-recursive: enforce rule that index matches head before merging
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jul 3, 2018, 20:05 UTC
- Message-ID
- <xmqqwoucozje.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <20180701012503.14382-9-newren@gmail.com>
Elijah Newren <newren@gmail.com> writes:
Show 9 quoted lines
> ...[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).
Show 15 quoted lines
> 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.