Re: [PATCH 7/7] [doc] ignore conflict markers in gitmergeconflicts.adoc

["Julia Evans" <julia@jvns.ca>]

On Wed, Oct 7, 2026, at 5:21 PM, Junio C Hamano wrote:
> "Julia Evans via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
>> Subject: Re: [PATCH 7/7] [doc] ignore conflict markers in gitmergeconflicts.adoc
>> From: Julia Evans <julia@jvns.ca>
>>
>> Signed-off-by: Julia Evans <julia@jvns.ca>
>> ---
>>  .gitattributes | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/.gitattributes b/.gitattributes
>> index 26490ad60a..0a0fc950b1 100644
>> --- a/.gitattributes
>> +++ b/.gitattributes
>> @@ -14,6 +14,7 @@ CODE_OF_CONDUCT.md -whitespace
>>  /t/oid-info/* text eol=lf
>>  /Documentation/git-merge.adoc conflict-marker-size=32
>>  /Documentation/git-merge-file.adoc conflict-marker-size=32
>> +/Documentation/gitmergeconflicts.adoc conflict-marker-size=32
>>  /Documentation/gitk.adoc conflict-marker-size=32
>>  /Documentation/user-manual.adoc conflict-marker-size=32
>>  /t/t????-*.sh conflict-marker-size=32

> I believe the
> plan is to squash this into the step that introduces the new file;
> when that happens, the patch title will disappear and we will not
> have to worry about it

Yes, I squashed it in the new version. I don't share your opinions
about how the title of this patch was worded but it's such a minor
point that I don't think it's worth discussing.

> By the way, some of the points above might be worth teaching in the
> material covering merge conflicts (i.e., this series).  I do not
> think many people write manuals on Git with examples of what a
> conflict block looks like ;-), but a run of seven '<', '=', '|', or
> '>' characters may appear in real payloads that users need to use,
> in contexts completely unrelated to ours.
>
> Setting 'conflict-marker-size' to a length that their payload is
> unlikely to use is a useful technique to be aware of.

I do not think that would be useful to explain in this series.
(since as you say Git's situation is unusual and it's not a good
practice to explain things that we don't think are relevant
 "just in case"). If users ask for it to be covered in the future
we can add it then.