git branch with fugitive, not always shown

[Dea1993]

environment

• vim: 8.1.0470
• vim-airline: 0.9
• vim-fugitive: 2.4 (downgrade to 2.3 works)
• OS: ArchLinux
• Have you reproduced with a minimal vimrc:
  enable syntax on and/or filetype indent on
• What is your airline configuration:

let g:airline_theme = 'powerlineish'
let g:airline_powerline_fonts = 1
let g:airline#extensions#tabline#enabled = 1
let g:airline#extensions#branch#enabled = 1

if you are using terminal:

• terminal: gnome-terminal 3.30.2
• $TERM variable: xterm-256color
• color configuration (:set t_Co?):

actual behavior

git branch (with vim-fugitive) not show if
syntax on
or
filetype indent on
are enabled
:echo fugitive#head() show the correct branch

expected behavior

see git branch on airline

[chrisbra]

cannot reproduce:

[Dea1993]

i've tried with your configuration file, but i've the same problem, i've also tried changing terminale (urxvt), but not solve.
i attach two screenshot.
if i open a file (psqrc) withous syntax, i can see the branch, if i open a file with sintax (python), i can't see git branch.
if i remove syn on i can see git branch everywhere

[chrisbra]

does it somehow happen later? It could be the async feature, that at the beginning it is not there. If you do :doautocmd BufWinEnter, does this change anything?

[chrisbra]

also try before running that autocommand :unlet! b:airline_head

[chrisbra]

oh and what revision are you on for fugitive?

[Dea1993]

does it somehow happen later? It could be the async feature, that at the beginning it is not there. If you do :doautocmd BufWinEnter, does this change anything?

git branch is shown only on some source code (for example configuration file of postgres, that hasn't auto intendation and hasn't colored syntax).
i've tried execute

:unlet! b:airline_head
:doautocmd BufWinEnter

nothing happends.

if i insert

unlet! b:airline_head
doautocmd BufWinEnter

inside my .vimrc, i receive this error when i launch vim

no corresponding autocommand

(or a similar message)

vim fugitive version and revision is 2.4-2

thanks for the support

[chrisbra]

is that the latest revision of vim-fugitive? you mentioned something like it worked with vim-fugitive 2.3 and not working with vim-fugitive 2.4 so I am asking.

In case it is not working, what is the output of :echo airline#extensions#branch#head() (please unlet b:airline_head first). What about the output of echo FugitiveHead(7) and :echo fugitive#head(7)?

[Dea1993]

:echo fugitive#head(7)

:echo airline#extensions#branch#head()
:echo FugitiveHead(7)
:echo fugitive#head(7)

all these commands returns the correct name of the current branch

instead this command

:unlet b:airline_head

not works, i receive

E108: Variable non-existent: "b:airline_head"

this is the last version and revision of the package (i've already reported the problem on archlinux bugs page, and vim-fugitive github page, but i was told that this isn't a vim-fugitive problem, but airline problem).
the previous version (2.3) works correctly

[chrisbra]

E108: Variable non-existent: "b:airline_head"

That is okay, that's whay use the '!' attribute.

Please use commit ids to identify the release, as I am not sure to what version 2.4 refers to. Also can you please link me to those bug reports?

So if airline#extensions#branch#head() works, what about :echo airline#extensions#branch#get_head()?

[chrisbra]

Oh, and please use the most recent plugin from the repository, not from a package of your linux distro.

[Dea1993]

airline#extensions#branch#get_head()

i've uninstalled vim-fugitive from distro package and i've installed from github (https://github.com/tpope/vim-fugitive#installation).

if i execute

echo airline#extensions#branch#get_head()

returns git branch name, and branch symbols

That is okay, that's whay use the '!' attribute.

what do you mean?

Please use commit ids to identify the release

if i enter inside vim-fugitive folder inside ~/.vim/bundle/vim-fugitive
and run git log, this is the last commit id
0fd64f8fbfa7eda26a7dcc7d3102843edbe2324d

please link me to those bug reports?

tpope/vim-fugitive#1116
https://bit.ly/2JeWtKz

[chrisbra]

returns git branch name, and branch symbols

So it works?

what do you mean?

Use unlet!

Are you also using vim-airline from this repository or are you using the packaged version from arch?

[Dea1993]

Are you also using vim-airline from this repository or are you using the packaged version from arch?

the problem seems the package from archlinux is not updated to the last commit, because if i install it with Pathogen, works.
sorry for report.

[chrisbra]

the problem seems the package from archlinux is not updated to the last commit,

Okay, than please let them know to update their package.

[anthraxx]

the problem seems the package from archlinux is not updated to the last commit,

Okay, than please let them know to update their package.

We don't package random git commits and HEADs, if there is a new git tag we are happy to package it immediately but we ship releases not arbitrary snapshots.

[chrisbra]

Well, I don't tag a new release just because a bug has been fixed. I'll happily create a new release tag once I think enough new features are there to warrant a release. But we are not there yet.

[anthraxx]

well its nearly 1 year worth of development and 199 commits. IMO release early and release often, you don't need to have a minimum new feature count of 42 before a release is allowed to be tagged.
If you ask me, tag early and tag often, but i totally accept its your decision, as is ours to not bump to random snapshots that are not tagged. 🐱

[chrisbra]

How about you at least cherry-pick 30a3c4f into the existing package to make sure it works correctly with the update vim-fugitive?

There are a couple of other one that might be relevant, not sure:
a1680cc
981b830
and those two from @tpope
964f53a
db45cdd

[anthraxx]

Well honestly you can't expect every distros to individually backport "thousands" of patches, thats what a patch-release is for, like 0.9.1. If you feel like the minor version components need to have a certain amount of new features to be increased it doesn't mean point releases can't or shouldn't be done.
Don't quite see why packagers across various distros should all individually backport arbitrary number if potential problems if the only reasoning is that there are not enough new features for a tag.

[chrisbra]

Well, we are not talking about thousands of patches, just at a minimum one that fixes this bug (in your package) and we are talking about vim script here, nothing complicated to build and compile and the change is only about a couple of lines of Vimscript.

Honestly I expect more people to simply clone the repository (using one of the modern plugin managers) rather than waiting for a distro to package a plugin. Alternatively, you can make the vim-airline package depend on vim-fugitive 0.2.3 but I don't think this is what users want.

I might tag a release, but that would need some more fixes (especially I'd like to have at least #1779 fixed) plus a stabilization period which I haven't come to yet (and I have enough other work to be done as well). So sorry, I cannot promise to tag a release soon.

[anthraxx]

@chrisbra To be clear to you don't take my message here the wrong way: I argue with no ill intend and absolutely zero pun or personal critic in any mean. Just honestly trying here the same as you do: Serve our users as good as possible -- with different point of views obviously 😄

I'm missing the bottom line here. On one hand, according to you, the majority of users uses the latest git HEAD anyway, why not then tag a point release that fixes obvious incompatibilities? You argue that patches should be backported, of so, why not just fix #1779 later and expect either a backport on that as well. I'm wondering because people here are encouraged to use git but on the other hand there seems to be a bug serious enough in your eyes to not tag a release.

The thing here is that the mentioned patch doesn't apply cleanly on the last tag. I'm sure you would not want to debug bug reports here that occurred because of downstream adjustments of backports that did not apply cleanly but were never ever in that particular form in the upstream tree (at least I would be very annoyed to debug such a potential problem). Sure more patches could be backported as you mentioned and also more patches that affected surrounding refactorings so at the end the patch for this bug could apply cleanly... and i agree its "just" VimScript and not rocket science but its still code and lot of things changed in the meanwhile, the more adjustments and backport patches are needed so one thing applies the higher the like hood to introduce incompatibility or internal API regression that was never a problem in the git tree itself.

I really believe doing more frequent point releases here would just solve problems and you seemu to expect most people to use a git commit anyway so nothing really stops from tagging, right? I understand that you are annoyed to wait for distros to pick up a new version, but here is one that is literally sitting and waiting for one to happen to instantly pick it up 😋

We all have lot of other work to be done, me included, so I really hope you don't feel like this is wasting your time. I'm just trying to improve situation as well 😸

[chrisbra]

@anthraxx I am currently planing a release (see #1820) for mid of december.