tpope / vim-git Goto Github PK

When having GIT localized the output of e.g. :Gstatus in fugitive is not highlighted properly anymore. This issue is related to tpope/vim-fugitive#228

What I did to force GIT to use english in fugitive for now is putting

    let g:fugitive_git_executable = 'LANG=en git'

into my .vimrc.

tw=72 for body makes sense per Linus's best practices on gitcommit messages, but there is no visual clue and auto-wrap is not turned on. I would be in favor of one or both following solutions:

1. Set a color column. Yes, it's "invasive", but just because no one else is doing it on shipped vim plugins doesn't mean it's not the right solution. My bet is once committers see the visual color column clue they know what to do on the tw=72 for body. An alternate solution is to color body chars past 72 much like is already done for subject past 50.
2. set fo=tc which would force auto-wrap at tw=72? Now you have to dig much harder to write bad body.

You seem to be in favor of clean commit messages? How do we really get there and make everyone both aware and better git users? The above two combined seems potent enough to make a difference.

The summary line length is currently at 50. The best reason I could find for that was your blog post about commit messages.

The subject line is used all over Git, oftentimes in truncated form if too long of a message was used

From what I've found, up to 58 characters works just as well -- it's not being truncated on GitHub or in Git, though I haven't tried an exhaustive list of commands. I haven't tried any more than 58, but will update when I do.

IIRC, summary lines above ~50 chars would previously show up as truncated on GitHub, but they must have increased the limit. It now seems to be truncated at 70 chars (so 69 is max).

When I use bulleted lists with - or * lines that are longer than 72 chars do not wrap with a hanging ident.

What I'd expect:

- This is a long line that wraps
  and aligns the second line and
  even the third line.

What I get:

- This is a long line that wraps
and unfortunately it indents all 
the way over to the left.

I dug into this locally for quite awhile but couldn't figure out the right combination of settings for formatoptions to make this work.

I think the source of the issues arises from these files, but I'm not sure.

Whenever I do a git commit or git rebase -i or anything else I get a readonly nomodifiable buffer, so I have to reenable both by hand because I can't seem to make it work from my filetype.vim.

Is there something I'm doing wrong or some kind of configuration that's triggering this behavior?

Hello!

If I say "git commit -v" I get this: http://gist.github.com/638460. Syntax highlighting stops after the list of untracked files.

Thanks!

Git allows to customise the comment character and I use ; to not conflict with Markdown headers. It would be handy to be able to customise that in the syntax highlighting as well.

This is my first time with Pathogen and my second plugin installed, I am not sure if the plugin is loading properly. It appears line 1 and 2 are working correctly but line 3+ don't appear to be getting flagged if longer than 72 characters.

The first plugin I have is Vim Sensible, not sure if that has any conflict but I wouldn't think it would.

Within my gitconfig, I have the my core.commentChar set to | due to using # in majority of my commits for other non-comment related things. Unfortunately, it looks like the gitcommit syntax is hardcoded to use ^#.*.

I had a bit of a poke around and I couldn't find a way that instead of using a hardcoded value, I could rely on the value from core.commentChar. Is this something that is possible? If you have some documentation or guides to point me at, I'm happy to submit a PR for this one.

Thanks!

Wouldn't it be great if the plugin will do something like setlocal colorcolumn=50,72 for git commit buffers?

Currently, when wrapping lines starting with an asterisk in the commit message it gets wrapped as though it was a C comment:

* text text text text text text text text text text text text text text text text text text text text text text text

* text text text text text text text text text text text text text text 
* text text text text text text text text text

Would it be possible to add something like

setlocal comments-=mb:*
setlocal comments+=fb:*

to the gitcommit format specifier in order to allow reasonable wrap-handling of asterisk-bullted lists in commit messages, or would this interfere with the diff format of git commit --verbose?

Would be nice if the GITCOMMIT file types supported the commentchar setting. I've been using '$' instead of '#' so that I can tack bug numbers to the end of messages and get the automatic github linking, e.g.

{title}

{description}

#{bug}

I've hacked the plugin locally to fix syntax highlighting but have failed in my attempts to generalize it by grabbing git config core.commentchar. I may take another crack at fixing this but any pointers would be appreciated since I'm a noob when it comes to VimL.

See also
http://stackoverflow.com/questions/16164624/vim-syntax-highlighting-for-git-commit-messages-custom-commentchar

I'm not sure why it's even in there; but it's really annoying for my tab key to suddenly work differently.

Is there some good reason to change tabstop in a git commit message buffer?

I would like all trailer names (like "Signed-off-by") to have a highlight group, so that I may apply a color to make them distinct. This is a more generic version of #69.

The best reference I've been able to find so far on their syntax is the git-interpret-trailers(1) man page. (Scanning through the git source, all of the parsing is handled in trailer.c & trailer.h.)

The man page references RFC 822, and for ease here is the declared BNF for headers:

 header      =  field-name ":" [ field-body ] CRLF
 
 field-name  =  1*<any CHAR, excluding CTLs, SPACE, and ":">
 
 field-body  =  field-body-contents
                [CRLF LWSP-char field-body]
 
 field-body-contents =
               <the ASCII characters making up the field-body, as
                defined in the following sections, and consisting
                of combinations of atom, quoted-string, and
                specials tokens, or else consisting of texts>

There is also the ability to fold a trailer's contents (in RFC 822's language, the "field body") over multiple lines, so long as the additional lines are prefixed with whitespace. Not sure how to represent that using vim's regex, or if that's something that can be skipped for now. I have yet to see any git commits with a multi-line trailer, but wanted to mention it.

In this blog post you argue for clear git commit subject lines. I wondered how strongly you feel about the 50 character limit you mention there.

For example, in the ghc project we're up to ticket numbers in the 10000s. Following the 50 character limit leaves very little room to include the ticket number in the subject line.

You mention it's not a hard limit, and I wondered if we could still change it. I cannot find that many tools which actually suffer from subject lines between 50 and say 72 characters (gitweb being the exception). Github seems to use a 72 limit for the subject, which works great for me also.

Would a pull request to change the vim syntax highlighter to warn after 72 characters for the commit subject be accepted?

I notice you use very short subject lines yourself, which is of course great.

Originally in neovim/neovim#18396

Steps to reproduce:

• Set neovim as your git editor
• Run git commit
• Copy the commit message from lnls-dig/openMMC@fc56ded
• Select the commit body and press gq to auto format it

The commit message in question:

fpga_spi: guarantee board_diagnostic_t alignment

fpga_spi.c reads from this struct by aliasing it to an uint32_t pointer
and using that to iterate through it. That means it should be aligned to
4 bytes, to so the reads don't generate faults, and that its size should
be a multiple of 4, otherwise we'd have to deal with defining incomplete
reads for the last element.

The commit body is changed to:

fpga_spi.c reads from this struct by aliasing it to an uint32_t pointer
and using that to iterate through it. That means it should be aligned to
4 bytes, to so the reads don't generate faults, and that its size should
  be a multiple of 4, otherwise we'd have to deal with defining
  incomplete reads for the last element.

Per neovim/neovim#18396 (comment) , this might not be possible to fix (or even considered a bug):

This is because the ftplugin for gitcommit sets formatoptions+=n and formatlistpat

But I'd like to bring it up to confirm.

Are there any plans to provide support for .gitignore files?

The syntax file for filetype=git includes syntax patterns for git word diff mode (git --diff --word-diff). However, if the first line after the diffLine @@ is empty the patterns fail to match and the whole diff block isn't highlighted anymore.

Example (set filetype=git):

@@ -124,7 +124,7 @@ typedef enum {
	BLOCK_NONE,
	BLOCK_STD,
	BLOCK_START
	BLOCK_[-DELETE-]{+ADD+},
	BLOCK_END,
} Mode;

Above @@ -124... is highlighted with diffLine, typedef enum { with diffSubname, [-DELETE-] with gitDiffRemoved and {+ADD+} with gitDiffAdded.
If I insert a line after @@ -124... the block of lines after @@ -124... stops being highlighted.

Description:
When the 'previewpopup' option is set to any value, doing :DiffGitCached will report E441: There is no preview window. This seems to be caused by the wincmd P here being disallowed in popup windows.

To Reproduce:

1. Start vim with vim --clean
2. Do :set previewpopup=height:10
3. Do set ft=gitcommit
4. Do :DiffGitCached
5. See the error

Tested on gvim 8.2.4127 and vim 8.1.2269

Hello Tim Pope,

First of all, thanks a lot for your contribution to this project and other vim plugins. You're making the world a better place.

I've noticed that the git and gitcommit syntax for gitDiffAdded and gitDiffRemoved don't work if an empty space is added in the code section, for example,

I looked into the git.vim syntax file and found out that it works if I make a small change in the gitDiff syntax by deleting the \!$ in the end condition like these:

" From
syn region gitDiff start=/^\%(diff --git \)\@=/ end=/^\%(diff --\|$\)\@=/ contains=@gitDiff fold
syn region gitDiff start=/^\%(@@ -\)\@=/ end=/^\%(diff --\%(git\|cc\|combined\) \|$\)\@=/ contains=@gitDiff

" To
syn region gitDiff start=/^\%(diff --git \)\@=/ end=/^\%(diff --\)\@=/ contains=@gitDiff fold
syn region gitDiff start=/^\%(@@ -\)\@=/ end=/^\%(diff --\%(git\|cc\|combined\) \)\@=/ contains=@gitDiff

After fixing the syntax:

I don't think this is the right way to fix this issue and am wondering if this is an issue only for me.

Could you explain why this is happening?

Thanks.

Hey Tim,
I was wondering what your opinion on highlighting characters past 72 on the gitcommitFirstLine was. I sometimes use Atom's commit editor, and I think they do a great job at this ⬇️

Albiet 80 characters, not 72.

I'm aware that the commit line will wrap the next word after 72 characters in the gitcommitFirstLine, but I think the highlighting would make my brevity more obvious, faster. If you think this is a good idea, I'd be more than happy to volunteer my time to implement the behavior and send a Pull Request.

Thank you so much for all of your work ❤️

Having shot myself in the foot by rewriting already pushed history, it occurred to me that perhaps I could have the commits list in interactive rebase reflect the commits' push status in color. If lines of commits that I've already pushed to a remote were colored red (or any sufficiently differentiating color), I might actually notice when I'm about to screw up again.

To illustrate what I mean, here's a mockup I made. This is what it would look like if this was my commit history, and 8b0ce7b was the last commit I had already pushed to a remote:

I have no previous experience in modifying syntax highlighting code, and I have no idea if what I'm suggesting is even possible with vim, so I figured I'd open this request first in case it's a silly idea, or conversely, if you deem this useful enough to implement yourself.

Since @75bc1628833ee1f1d8ecb8a66c5df852554c9a19, issuing a git commit command does not set filetype to gitconfig.

this is a very to fix bug, a single comma suffice.

diff --git a/ftdetect/git.vim b/ftdetect/git.vim
index 32b17ec..09d169c 100644
--- a/ftdetect/git.vim
+++ b/ftdetect/git.vim
@@ -1,5 +1,5 @@
 " Git
-autocmd BufNewFile,BufRead *.git/{modules/**/}{COMMIT_EDIT,MERGE_}MSG set ft=gitcommit
+autocmd BufNewFile,BufRead *.git/{,modules/**/}{COMMIT_EDIT,MERGE_}MSG set ft=gitcommit
 autocmd BufNewFile,BufRead *.git/config,.gitconfig,.gitmodules set ft=gitconfig
 autocmd BufNewFile,BufRead *.git/modules/**/config             set ft=gitconfig
 autocmd BufNewFile,BufRead git-rebase-todo                     set ft=gitrebase

Couldn't you highlight branch name in git log --decorate and git log --decorate --graph?

In --all mode, highlighting would be strongly expected to find branches easily.

I started the first step with the diff below,
however, by my poor vim-syntax knowledge,
I couldn't avoid the false positive that contains () in commit message...

--- a/syntax/git.vim
+++ b/syntax/git.vim
@@ -18,8 +18,10 @@ syn region gitHead start=/\%(^commit\%( \x\{4,\}\)\{1,\}\%(\s*(.*)\)\=$\)\@=/ en
 " minimize false positives by verifying contents of buffer
 if getline(1) =~# '^\x\{7,\} ' && getline('$') =~# '^\x\{7,\} '
   syn match gitHashAbbrev /^\x\{7,\} \@=/ contains=@NoSpell
+  syn match gitHashRef    /(.\{-})/ contains=@NoSpell
 elseif getline(1) =~#     '^[|\/\\_ ]\{-\}\*[|\/\\_ ]\{-\} \x\{7,\} '
   syn match gitHashAbbrev /^[|\/\\_ ]\{-\}\*[|\/\\_ ]\{-\} \zs\x\{7,\} \@=/ contains=@NoSpell
+  syn match gitHashRef    /(.\{-})/ contains=@NoSpell
 endif
 " git log --graph
 syn region gitGraph start=/\%(^[|\/\\_ ]*\*[|\/\\_ ]\{-\} commit\%( \x\{4,\}\)\{1,\}\%(\s*(.*)\)\=$\)\@=/ end=/^\%([|\/\\_ ]*$\)\@=/ contains=@NoSpell
@@ -74,12 +76,13 @@ syn match  gitDate      /-\=\d\+ [+-]\d\d\d\d\>/               contained
 syn match  gitDate      /\<\d\+ \l\+ ago\>/                    contained
 syn match  gitType      /\<\%(tag\|commit\|tree\|blob\)\>/     contained nextgroup=gitHashAbbrev skipwhite
 syn match  gitReference /\S\+\S\@!/                            contained
-syn match  gitHash      /\<\x\{40,\}\>/             contained nextgroup=gitIdentity,gitHash skipwhite contains=@NoSpell
+syn match  gitHash      /\<\x\{40,\}\>/             contained nextgroup=gitIdentity,gitHash,gitHashRef skipwhite contains=@NoSpell
 syn match  gitReflogOld /^\x\{40,\} \@=/            contained nextgroup=gitReflogNew skipwhite contains=@NoSpell
 syn match  gitReflogNew /\<\x\{40,\} \@=/           contained nextgroup=gitIdentity skipwhite contains=@NoSpell
-syn match  gitHashAbbrev /\<\x\{4,\}\>/             contained nextgroup=gitHashAbbrev skipwhite contains=@NoSpell
-syn match  gitHashAbbrev /\<\x\{4,39\}\.\.\./he=e-3 contained nextgroup=gitHashAbbrev skipwhite contains=@NoSpell
+syn match  gitHashAbbrev /\<\x\{4,\}\>/             contained nextgroup=gitHashAbbrev,gitHashRef skipwhite contains=@NoSpell
+syn match  gitHashAbbrev /\<\x\{4,39\}\.\.\./he=e-3 contained nextgroup=gitHashAbbrev,gitHashRef skipwhite contains=@NoSpell
 syn match  gitHashStage /\<\x\{4,\}\>/              contained nextgroup=gitStage skipwhite contains=@NoSpell
+syn match  gitHashRef /(.\{-})/                     contained skipwhite contains=@NoSpell
 syn match  gitStage     /\<\d\t\@=/                 contained
 
 
@@ -98,6 +101,7 @@ hi def link gitDate              Number
 hi def link gitMode              Number
 hi def link gitHashStage         gitHash
 hi def link gitHashAbbrev        gitHash
+hi def link gitHashRef           gitIdentityKeyword
 hi def link gitReflogOld         gitHash
 hi def link gitReflogNew         gitHash
 hi def link gitHash              Identifier

Could you support syntax highlighting for git range-diff output?

It's useful in rebasing...

Sample output of the command is below:

% git range-diff base..tmp base..master
1:  b92fe39 = 1:  b92fe39 a
2:  4a49bd2 = 2:  4a49bd2 b
3:  cd2481d = 3:  cd2481d c
4:  b8f778d ! 4:  b804dd4 e
    @@ Metadata
     Author: xxxxxxxx <[email protected]>
     
      ## Commit message ##
    -    e
    +    e~
     
      ## test.txt ##
     @@
      a
      b
      c
    -+e
     +e
      c
      b

% git log --graph --all -p
* commit b804dd468388efe6d08c2f4230c5cd3ceda3f00c (HEAD -> master)
| Author: xxxxxxxx <[email protected]>
| Date:   xxx xxx xx xx:xx:xx xxxx +xxxx
| 
|     e~
| 
| diff --git a/test.txt b/test.txt
| index 2d4ca2c..3a3e0e5 100644
| --- a/test.txt
| +++ b/test.txt
| @@ -1,6 +1,7 @@
|  a
|  b
|  c
| +e
|  c
|  b
|  a
|   
| * commit b8f778db7a4794d4fe429a2adc77442990087dad (tmp)
|/  Author: xxxxxxxx <[email protected]>
|   Date:   xxx xxx xx xx:xx:xx xxxx +xxxx
|   
|       e
|   
|   diff --git a/test.txt b/test.txt
|   index 2d4ca2c..2f04e0a 100644
|   --- a/test.txt
|   +++ b/test.txt
|   @@ -1,6 +1,8 @@
|    a
|    b
|    c
|   +e
|   +e
|    c
|    b
|    a
| 
* commit cd2481dd1d9e9ad0dcd649cdd48d61de9c1d1810
| Author: xxxxxxxx <[email protected]>
| Date:   xxx xxx xx xx:xx:xx xxxx +xxxx
| 
|     c
| 
| diff --git a/test.txt b/test.txt
| index f7a2241..2d4ca2c 100644
| --- a/test.txt
| +++ b/test.txt
| @@ -1,4 +1,6 @@
|  a
|  b
| +c
| +c
|  b
|  a
| 
* commit 4a49bd20b6bedcaa74d4b3121a578f48baaba1d7
| Author: xxxxxxxx <[email protected]>
| Date:   xxx xxx xx xx:xx:xx xxxx +xxxx
| 
|     b
| 
| diff --git a/test.txt b/test.txt
| index 7e8a165..f7a2241 100644
| --- a/test.txt
| +++ b/test.txt
| @@ -1,2 +1,4 @@
|  a
| +b
| +b
|  a
| 
* commit b92fe39785c92aa52a471f822ff77e9302314279
| Author: xxxxxxxx <[email protected]>
| Date:   xxx xxx xx xx:xx:xx xxxx +xxxx
| 
|     a
| 
| diff --git a/test.txt b/test.txt
| new file mode 100644
| index 0000000..7e8a165
| --- /dev/null
| +++ b/test.txt
| @@ -0,0 +1,2 @@
| +a
| +a
| 
* commit b8fbc899b2aa83bba97dccaf2b4dc1a89dffef19 (base)
  Author: xxxxxxxx <[email protected]>
  Date:   xxx xxx xx xx:xx:xx xxxx +xxxx
  
      Initial commit

Now I sets some :match highlighting by self as below.

I was wondering if such highlighting was supported natively...

let g:match_rangeDiff  = []

let g:match_rangeDiff += [ { 'group' : 'DiffAdd'     , 'pattern' : '^    \zs+.*'      , 'priority' : 10 , 'id' : 100 } ]
let g:match_rangeDiff += [ { 'group' : 'DiffDelete'  , 'pattern' : '^    \zs-.*'      , 'priority' : 10 , 'id' : 101 } ]
let g:match_rangeDiff += [ { 'group' : 'diffAdded'   , 'pattern' : '^    [ +-]\zs+.*' , 'priority' : 10 , 'id' : 102 } ]
let g:match_rangeDiff += [ { 'group' : 'diffRemoved' , 'pattern' : '^    [ +-]\zs-.*' , 'priority' : 10 , 'id' : 103 } ]

call setmatches(g:match_rangeDiff)

I have a habit, which I would like to break, of ending the first line of my commits with a full stop. To do this I want to highlight the full stop but I can't figure out how.

After looking at these lines I tried this but it didn't work:

au Filetype gitcommit syn match ErrorMsg "\.$" containedin=gitcommitFirstLine

It also didn't work without the containedin.

Any pointers would be much appreciated. Many thanks in advance.

After editing a commit message and saving but not exiting the buffer (:w instead of :x), the red and green diff below the message stops being colored.

Consider following alias in ~/.config/git/config

[alias]
  config-user-ME = !git config user.name "ME"; git config user.email "[email protected]"

In $VIMRUNTIME/ftplugin/gitconfig.vim comments are correctly setup,

setlocal comments=:#,:; commentstring=;\ %s

However, the syntax highlighting gets messed up for such aliases.

I guess there is no perfect solution. I use the workaround using && instead of ; which is semantically not identically but who cares here

In my .vimrc I have

" Add spell checking and automatic wrapping at the recommended 72 columns to commit messages.
autocmd Filetype gitcommit setlocal spell textwidth=72

Does vim-git already take care of this?

ftplugin/gitcommit.vim sets nomodeline but ftplugin/gitrebase.vim does not. Should it? Rebasing my .dotfiles repo which has commit messages like:

vim: update plugin xyz

Causes modeline parsing errors from vim

Hi,

Thanks for your amazing plugins. Can you provide a license with this plugin as well please?

Many thanks!

git-repo.zip

inside the attached Git repository I type git show and scroll down a little bit I see this (correct diff):

However when I type git commit --amend which opens Vim, and school down a bit I see this incorrect syntax highlighting on the TODO line - It is green instead of red:

I am using the latest Vim polyglot

I found that vim-git has been in vim-8.0 by default, I'm not sure whether vim-git has been integrated in previous version, and is that means we don't need to install vim-git as a plugin. Or it has some difference with the default version?

Some context on how to load this into VIM/Git would be helpful.
Possibly a simple readme would be helpful.
I've used GIT for a long time, however, although I use VIM for most text editing in a terminal I'm still a bit of a noob.

Vim newbs, but aspiring fanboys, like me could use some documentation on how to use this plugin :)