On 08/27, Junio C Hamano wrote: > Thomas Gummerer <t.gummerer@xxxxxxxxx> 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. Right, I was more thinking along the lines of using the stages in the index to redo the merge and get the information that way. But that may not work as well with using 'git rerere' from the command line, and have other backwards compatibility woes, that I didn't quite think through yet :) > 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. Right, I wasn't aware of the conflict-marker-size attribute. Thanks for mentioning it! > 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 I do think that would be a good idea. I am wondering what the right value is though. Seeing such a long conflict marker before I knew about this setting would have struck me as odd, and probably made me try and track down where it is coming from. But on the other hand it makes the conflict markers very easy to tell apart from the rest of the lines that kind of look like conflict markers. I think these tradeoffs probably make it worth setting them to a value this large. One other file that I see needs such a treatment is Documentation/gitk.txt, where the first header is 7 "="s, and therefore could confuse 'git rerere' as well. Arguably that's less important, as there's unlikely to be a conflict containing that line, but it may be worth including for completeness sake. Maybe something like this? Though it may be good for others to chime in if they find this helpful or whether they find the long conflict markers distracting. --- >8 --- Subject: [PATCH] .gitattributes: add conflict-marker-size for relevant files Some files in git.git contain lines that look like conflict markers, either in examples or tests, or in the case of Documentation/gitk.txt because of the asciidoc heading. Having conflict markers the same length as the actual content can be confusing for humans, and is impossible to handle for tools like 'git rerere'. Work around that by setting the 'conflict-marker-size' attribute for those files to 32, which makes the conflict markers unambiguous. Helped-by: Junio C Hamano <gitster@xxxxxxxxx> Signed-off-by: Thomas Gummerer <t.gummerer@xxxxxxxxx> --- .gitattributes | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/.gitattributes b/.gitattributes index 1bdc91e282..49b3051641 100644 --- a/.gitattributes +++ b/.gitattributes @@ -9,3 +9,7 @@ /command-list.txt eol=lf /GIT-VERSION-GEN eol=lf /mergetools/* eol=lf +/Documentation/git-merge.txt conflict-marker-size=32 +/Documentation/gitk.txt conflict-marker-size=32 +/Documentation/user-manual.txt conflict-marker-size=32 +/t/t????-*.sh conflict-marker-size=32 -- 2.18.0.1088.ge017bf2cd1
