Re: [PATCH 7/7] [doc] ignore conflict markers in gitmergeconflicts.adoc
- From
Julia Evans <julia@jvns.ca>
- Date
- Oct 9, 2026, 12:06 UTC
- Message-ID
- <d0797b01-14ce-4ead-bdd6-84d7bf7c0aac@app.fastmail.com>
- In-Reply-To
- <xmqqse2h5hql.fsf@gitster.g>
On Wed, Oct 7, 2026, at 5:21 PM, Junio C Hamano wrote:
Show 22 quoted lines
> "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.
Show 9 quoted lines
> 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.