Re: [RFC/WIP PATCH 0/3] Modifications to handling of non-textual file merge conflicts

[Junio C Hamano <gitster@pobox.com>]

Elijah Newren <newren@gmail.com> writes:

> 1) Representative example: A modify/delete conflict; the path in question
> in the working tree would have conflict information at the top of the file
> followed by the normal file contents; thus it could be of the form:
>
>     <<<<<<<< HEAD
>     Conflict hint: This block of text was not part of the original
>     branch; it serves instead to hint about non-textual conflicts:
>       MODIFY/DELETE: path foo modified in HEAD and deleted in BRANCH
>     ========
>     Conflict hint: This block of text was not part of the original
>     branch; it serves instead to hint about non-textual conflicts:
>       MODIFY/DELETE: path foo modified in HEAD and deleted in BRANCH
>     >>>>>>>> BRANCH
>     Lorem ipsum dolor sit amet, consectetuer sadipscing elitr,
>     sed diam nonumy eirmod tempor invidunt ut labore et dolore
>     magna aliquyam erat, sed diam voluptua. At vero eos et
>     accusam et justo duo dolores et ea rebum. Stet clita kasd
>     gubergren, no sea takimata sanctus est Lorem ipsum dolor
>     sit amet.
>
> Alternative ideas for handling the explanatory text here are welcome.

In a modify/delete conflict, we currently do not leave any in-file
clue, so smudging the modified side like this might be a change that
helps those who "grep e '<<<<<<<'" to find the set of paths that
need to be examined.  I personally do not feel it would be all that
useful, as "ls-files -u" is how I'd learn about these paths.

What I would want to see when faced to a modify/delete conflict is
how the modification side changed the contents, as the change, or
its moral equivalent, would need to be ported to other locations in
the context of the deleting side.  But I am not sure if it makes
sense to attempt to somehow include "diff HEAD...MERGE_HEAD" (or the
other way around) in the file to show the contents change on the
modification side.

> 2) Representative example: A binary edit/edit conflict.  In this case,
> it would be inappropriate to put the conflict markers inside the
> binary file.  Instead, we create another file (e.g. path~CONFLICTS)
> and put conflict markers in it:
>
>     <<<<<<<< HEAD
>     Conflict hint: This block of text was not part of the original
>     branch; it serves instead to hint about non-textual conflicts:
>       BINARY conflict: path foo modified in both branches
>     ========
>     Conflict hint: This block of text was not part of the original
>     branch; it serves instead to hint about non-textual conflicts:
>       BINARY conflict: path foo modified in both branches
>     >>>>>>>> BRANCH
>
> This file would also be added to the index at stage 1 (so that 'git merge
> --abort' would clean this file out instead of leaving it around untracked,
> and also because 'git status' would report "deleted in both" which seems
> reasonable).
>
> This type of example could apply for each of the following types of
> conflicts:
>   * binary edit/edit
>   * any of the conflicts from type 1 when binary files are involved
>   * symlink edit/edit (or add/add)
>   * symlink/submodule
>   * symlink/directory
>   * directory/submodule
>   * submodule/submodule
>
> It could also apply to the following new corner case conflict types from
> directory rename detection:
>   * N-way colliding paths (N>=2) due to directory renames
>   * directory rename split; half renamed to one directory and half to another

Hmph, I am starting to wonder if it may be easier to access if
instead you did not touch any working tree file to do any of the
above, and instead write a single file in $GIT_DIR/ to explain what
kind of conflicts these paths are involved in.  That would probably
give a better and easier-to-read summary than "ls-files -u" output.

Or do we have _enough_ information in the "ls-files -u" already to
infer "Ah, we are in symlink edit/edit conflict.", etc.?  If so,
perhaps "git status" can be extended to show what kind of conflict
these paths are in by reading the higher-stage index entries (and
lack of stages thereof, when dealing with a conflict with deletion
involved)?