Open zivarah opened 8 months ago
@tpope would you be open to a pull request that addresses this via a "fugitive" section in git-config as proposed at the end of the initial issue post? I'm happy to put one together if that's a path you're willing to take.
It looks like the format string used to display lines in the status buffer is hardcoded:
Has there been any consideration for allowing this to by customized? Taking a simple example of wanting to display the commit author:
Another use case I could see would be floating a specific trailer (for a bug ID or some other oft-used trailer).
Technically, it certainly appears to be pretty trivial: just allow defining some new
g:fugitive_log_format
value, default it to "%s", and then plop that value into this string (keeping the hard-coded%h%x09
so that the user can't mess that up).The main question seems to be how to handle different desired formats in different repositories (which I know you were hesitant to commit to a specific path for in https://github.com/tpope/vim-fugitive/issues/2260#issuecomment-1913318380).
My initial thought was that it could be fairly easily handled via some sort of
pretty.<name>
git config:pretty.fugitive = %s
globallypretty.fugitive = %<(15,trunc)%cn %s
in a specific repog:fugitive_log_format
tofugitive
... ['--pretty=%h%x09' . g:fugitive_log_format] ...
However, git doesn't seem to have any special syntax to allow plopping a pretty alias name into a format string recursively like that.
This would work if we allowed the user to override the whole string:
pretty.fugitive = format:%h%x09%s
globallypretty.fugitive = format:%h%x09%<(15,trunc)%cn %s
in a specific repog:fugitive_log_format
tofugitive
... ['--pretty=' . g:fugitive_log_format] ...
But now of course we've given the user a terrible footgun to break the parsing.
So unfortunately I'm not sure how to solve this without either:
At the risk of opening a can of worms: Have you considered allowing fugitive config via git config (something that I know other clients like TortoiseGit have done) for those values that really warrant per-repo differences?
That feels fairly elegant to me, though also obvious enough that I assume there's probably some reasons you've been hesitant to go that route?