Thomas Gummerer <[email protected]> writes: > Agreed. I think it may be solvable if we'd actually get the > information about what belongs to which side from the merge algorithm > directly.
The merge machinery may (eh, rather, "does") know, but we do not have a way to express that in the working tree file that becomes the input to the rerere algorithm, without making backward-incompatible changes to the output format. In a sense, that is already a solved problem, even though the solution was done a bit differently ;-) If the end users need to commit a half-resolved result with conflict markers (perhaps they want to share it among themselves and work on resolving further), what they can do is to also say that these are now part of contents, not conflict markers, with conflict-marker-size attribute. Perhaps they prepare such a half-resolved result with unusual value of the attribute, so that later merge of these with standard conflict marker size will not get confused. That reminds me of another thing. I've been running with these in my $GIT_DIR/info/attributes file for the past few years. Perhaps we should add them to Documentation/.gitattributes and t/.gitattributes so that project participants would all benefit? Documentation/git-merge.txt conflict-marker-size=32 Documentation/user-manual.txt conflict-marker-size=32 t/t????-*.sh conflict-marker-size=32
