On 6/28/22 5:49 PM, Junio C Hamano wrote: > "Derrick Stolee via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > >> -apply backend: When applying a patch, ignore changes in whitespace in >> -context lines. Unfortunately, this means that if the "old" lines being >> -replaced by the patch differ only in whitespace from the existing >> -file, you will get a merge conflict instead of a successful patch >> -application. >> +apply backend:;; > > Hmph, I am surprised that you took this, with an extra colon. Does > it format nicely? Well, this is somewhat of an "oops" because I honestly thought you had kept the colons in your comment, but it turns out that I misread it. I had replied with this doc-diff: - apply backend: When applying a patch, ignore changes in whitespace - in context lines. Unfortunately, this means that if the "old" lines - being replaced by the patch differ only in whitespace from the - existing file, you will get a merge conflict instead of a - successful patch application. + apply backend: + When applying a patch, ignore changes in whitespace in context + lines. Unfortunately, this means that if the "old" lines being + replaced by the patch differ only in whitespace from the + existing file, you will get a merge conflict instead of a + successful patch application. - merge backend: Treat lines with only whitespace changes as - unchanged when merging. Unfortunately, this means that any patch - hunks that were intended to modify whitespace and nothing else will - be dropped, even if the other side had no changes that conflicted. + merge backend: + Treat lines with only whitespace changes as unchanged when + merging. Unfortunately, this means that any patch hunks that + were intended to modify whitespace and nothing else will be + dropped, even if the other side had no changes that conflicted. So, we do have a render that doesn't look awful, but since we already have formatting that makes it clear these are subsections, the colons are not needed. Thanks, -Stolee
