Elijah Newren <newren@xxxxxxxxx> 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)?
