Re: [PATCH] merge-tree: sometimes, d/f conflict is not an issue
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:43:20
Possibly related (same subject, not in this thread)
- 2016-06-15 · Re: [PATCH] merge-tree: sometimes, d/f conflict is not an issue · Junio C Hamano <hidden>
- 2016-06-15 · Re: [PATCH] merge-tree: sometimes, d/f conflict is not an issue · Junio C Hamano <hidden>
- 2016-06-15 · Re: [PATCH] merge-tree: sometimes, d/f conflict is not an issue · Johannes Schindelin <hidden>
- 2016-06-15 · Re: [PATCH] merge-tree: sometimes, d/f conflict is not an issue · Johannes Schindelin <hidden>
- 2016-06-15 · Re: [PATCH] merge-tree: sometimes, d/f conflict is not an issue · Junio C Hamano <hidden>
Johannes Schindelin [off-list ref] writes:
quoted hunk ↗ jump to hunk
@@ -643,6 +643,20 @@ int threeway_merge(struct cache_entry **stages, index = stages[0]; head = stages[o->head_idx]; + /* + * Special case: do not care about a dir/file conflict, when + * the entries have not been touched. + * IOW if the ancestors are identical to the remote, and the + * index is the same as head, just take head. + */
Suppose paths "A" and "A/B" are involved, and you resolved with this logic to have "A" as a blob (so your HEAD does not have "A/B"). If the remote adds "A/B", what prevents the resulting index to have both "A" and "A/B" resolved at stage #0? A logic to do "if it is unchanged on one and changed in another, take changed one" already exists in later part of the code; your patch just circumvents D/F checks built into threeway_merge for this one case, and only because this one case happens to have reported. It doesn't feel right. IOW, don't make unpack-trees to make policy decisions on final resolution, unless it is operating under aggressive rule (where the caller explicitly allows it to make more than the "trivial" decisions). The caller (in this case, merge-recursive) should see A at stage #2 with A/B at stages #1 and #3 and decide what to do.