Spurious PlugClean message for .gitignore-d files

[myitcv]

Calling :PlugUpdate for https://github.com/myitcv/govim results in PlugClean required message and the plugin not being updated.

The git tree within .vim/plugged/govim is clean.

What's probably significant however is that git clean is not:

$ git clean -x -f -d -n
Would remove cmd/govim/.bin/

This is entirely intentional; I use the .gitignore-d ./cmd/govim/.bin to store installed binaries in commit-sha-named subdirectories, e.g.:

$ find cmd/govim/.bin/
cmd/govim/.bin/
cmd/govim/.bin/c2d29936502f35e1cbd3b8c284eefab5b42fb28d
cmd/govim/.bin/c2d29936502f35e1cbd3b8c284eefab5b42fb28d/gopls
cmd/govim/.bin/c2d29936502f35e1cbd3b8c284eefab5b42fb28d/govim
cmd/govim/.bin/bd60e5a5bf8c779cc9649fb6fa5022ed9a9f8431
cmd/govim/.bin/bd60e5a5bf8c779cc9649fb6fa5022ed9a9f8431/gopls
cmd/govim/.bin/bd60e5a5bf8c779cc9649fb6fa5022ed9a9f8431/govim

So I don't need to run clean here.

I've marked this as a bug because I think the plugin developer (me in this case!) probably knows what they are doing in such a situation.

But I probably don't have the context of understanding why PlugClean was created, and hence would appreciate thoughts/feedback.

---

VIM - Vi IMproved 8.1 (2018 May 18, compiled Apr  4 2019 12:59:10)
Included patches: 1-1103
Compiled by myitcv@myitcv
Huge version with GTK2 GUI.  Features included (+) or not (-):
+acl               ++builtin_terms    +cmdline_info      +diff              -farsi             -hangul_input      +libcall           +modify_fname      -mouse_sysmouse    +packages          -python3           +startuptime       +termguicolors     +toolbar           +vreplace          +xpm
+arabic            +byte_offset       +comments          +digraphs          +file_in_path      +iconv             +linebreak         +mouse             +mouse_urxvt       +path_extra        +quickfix          +statusline        +terminal          +user_commands     +wildignore        +xsmp_interact
+autocmd           +channel           +conceal           +dnd               +find_in_path      +insert_expand     +lispindent        +mouseshape        +mouse_xterm       -perl              +reltime           -sun_workshop      +terminfo          +vartabs           +wildmenu          +xterm_clipboard
+autochdir         +cindent           +cryptv            -ebcdic            +float             +job               +listcmds          +mouse_dec         +multi_byte        +persistent_undo   +rightleft         +syntax            +termresponse      +vertsplit         +windows           -xterm_save
-autoservername    +clientserver      +cscope            +emacs_tags        +folding           +jumplist          +localmap          -mouse_gpm         +multi_lang        +postscript        -ruby              +tag_binary        +textobjects       +virtualedit       +writebackup
+balloon_eval      +clipboard         +cursorbind        +eval              -footer            +keymap            +lua               -mouse_jsbterm     -mzscheme          +printer           +scrollbind        -tag_old_static    +textprop          +visual            +X11
+balloon_eval_term +cmdline_compl     +cursorshape       +ex_extra          +fork()            +lambda            +menu              +mouse_netterm     -netbeans_intg     +profile           +signs             -tag_any_white     +timers            +visualextra       -xfontset
+browse            +cmdline_hist      +dialog_con_gui    +extra_search      +gettext           +langmap           +mksession         +mouse_sgr         +num64             +python            +smartindent       -tcl               +title             +viminfo           +xim
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "$VIM/gvimrc"
    user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/home/myitcv/usr/vim/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK  -pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr
/include/libpng16 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libpng16   -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc   -L/usr/local/lib -Wl,--as-needed -o vim   -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfontconfig -lfreetype -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE  -lm -ltinfo -lnsl   -ldl  -L/usr/lib/x86_64-linu
x-gnu -lluajit-5.1  -L/home/myitcv/.pythons/2.7.15/lib/python2.7/config -lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic

• Type:
  • [x] Bug
  • [ ] Enhancement
  • [ ] Feature Request
  • [ ] Question
• OS:
  • [x] All/Other
  • [ ] Linux
  • [ ] OS X
  • [ ] Windows
• Vim:
  • [x] Terminal Vim
  • [x] GVim
  • [ ] Neovim

[junegunn]

vim-plug doesn't care if the directory contains additional files that are not tracked by git. So this doesn't look like an issue of vim-plug, but of your git configuration or something.

Check if any of the following commands returns with non-zero exit status. They shouldn't.

git rev-parse --abbrev-ref HEAD
git config -f .git/config remote.origin.url
git rev-parse HEAD

[myitcv]

Thanks very much for confirming.

Interesting:

git config -f .git/config remote.origin.url

fails with a non-zero exit code.

$HOME/.vim/plugged/govim is a submodule of $HOME/.vim

Is this a valid approach?

[junegunn]

Hmm, no. I don't put plugged in a git repository. I believe most people don't.

The plugins in the directory are managed by vim-plug; they are downloaded and updated by :PlugInstall, :PlugUpdate and not through git submodule update command.

[myitcv]

Ah ok, that explains what I'm seeing therefore. But I think it might be relatively straight forward to support this approach (which I like because the submodules help me keep track of exactly what commit a plugin is at)

Is there a reason we can't use the following for the remote url?

git config remote.origin.url

Because in a submodule that remote information is not in .git/config, but rather in the parent's submodule config.

[junegunn]

See https://github.com/junegunn/vim-plug/commit/36973defbd7d213300ce6cc268d368027f17af3c

One approach would be to remove -f option if GIT_CONFIG is not defined. But I'm a bit concerned that it might break someone else's configuration. And technically, it's not a perfect solution to the problem. Let me think about it.

I have maintained vim-plug for over 5 years by now, and you're actually the first one to report this exact problem, I can safely say that using submodules with vim-plug is not a common setup among the users. Many users have shied away from git submodules because of its unnecessary complexity for the purpose. I should also mention that there's :PlugSnapshot command if you want to "lock down" the versions of the plugins to some point.

[myitcv]

Thanks for the link to https://github.com/junegunn/vim-plug/issues/455. Ultimately in that case I think what you were doing was actually correct. i.e. if someone sets GIT_CONFIG then git should rightly obey that.

And reverting https://github.com/junegunn/vim-plug/commit/36973defbd7d213300ce6cc268d368027f17af3c would indeed fix the submodule case as well, because git would just do "the right thing".

I have maintained vim-plug for over 5 years by now, and you're actually the first one to report this exact problem, I can safely say that using submodules with vim-plug is not common a setup among the users

That's very much understood, and so I appreciate I'm potentially dealing with an edge case here.

I should also mention that there's :PlugSnapshot command if you want to "lock down" the versions of the plugins to some point.

Thank you, I didn't know about this. I still think I prefer the semantics and behaviour of git submodules, granted it is not a common use case.