Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > @@ -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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
