Gedit strips newlines when commit lacks a blank line

[idbrii]

I use git-svn on a project that don't follow good commit message formatting. We frequently have commit messages that are mostly nicely formatted -- except for the "one blank line" rule. Git generally handles this fine, but fugitive does not. :Gedit HEAD (or navigating :G blame and other commands that view a commit) will put the entire commit message on one line if it doesn't have a blank line after the first line.

git log --online also dumps it on one line.
:G show HEAD displays with expected newlines -- probably because it includes text from git verbatim?

---

Example commit message:

Capitalized, short (50 chars or less) summary
More detailed explanatory text, if necessary.  Wrap it to about 72
characters or so.  In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body.  The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, followed by a
  single space, with blank lines in between, but conventions vary here
- Use a hanging indent

Looks similar with :G show HEAD (but indented). However, :Gedit HEAD results in one massive line:

tree 97f0c365846b67412c5fadf7b0727893b72f75c2
parent 982feb7a65aef15e4cff157120808f439a9abdc4
author idbrii <idbrii@example.com> 2024-06-27 Thu 01:11:18 PM
committer idbrii <idbrii@example.com> 2024-06-27 Thu 01:24:35 PM

Capitalized, short (50 chars or less) summary More detailed explanatory text, if necessary.  Wrap it to about 72 characters or so.  In some contexts, the first line is treated as the subject of an email and the rest of the text as the body.  The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together. - Bullet points are okay, too - Typically a hyphen or asterisk is used for the bullet, followed by a   single space, with blank lines in between, but conventions vary here - Use a hanging indent

---

Tested on fugitive latest: d0c1a43. Used gvim on Win10 and vim on Ubuntu 22.04.4 LTS (WSL).

Minimal vimrc:

" Invoke with:
" gvim -Nu reprovimrc.vim -U NONE +"Gedit HEAD" c:/project/readme.md

let s:plugins = ['sensible']
let s:plugins += ['fugitive']

set runtimepath-=~/.vim
set runtimepath-=~/.vim/after
set runtimepath-=~/vimfiles
set runtimepath-=~/vimfiles/after
for plugin in s:plugins
    exec "set runtimepath^=~/.vim/bundle/". plugin
    exec "set runtimepath+=~/.vim/bundle/". plugin ."/after"
endfor
set viminfofile=NONE

set hlsearch
colorscheme desert

[tpope]

This is the the same thing that git show -s --format=%s does, correct? Probably not going to get fixed until that buffer gets redone.

[idbrii]

Yup. git show -s --format=%s does dump all the text on one line in commits lacking a blank line.

I see. It's due to the massive format in this line setting up a b:fugitive_type==commit buffer:

vim-fugitive/autoload/fugitive.vim

Line 3188 in d0c1a43

call s:ReplaceCmd([dir, '-c', 'diff.noprefix=false', '-c', 'log.showRoot=false', 'show', '--no-color', '-m', '--first-parent', '--pretty=format:tree%x20%T%nparent%x20%P%nauthor%x20%an%x20<%ae>%x20%ad%ncommitter%x20%cn%x20<%ce>%x20%cd%nencoding%x20%e%n%n%s%n%n%b', rev])