call minpac#status() not working anymore?

[ahmedelgabri]

I have this

command! -bar PackUpdate call plugins#init() | call minpac#update('', {'do': 'call minpac#status()'})

And I did update my plugins last week & after that, it doesn't show any info anymore

[k-takata]

Does the :mes command show anything?

[ahmedelgabri]

This is the output of :mes after I ran nvim -c "PackUpdate"

Already up-to-date: vim-citylights
Already up-to-date: vim-styled-components
Already up-to-date: vim-sayonara
Already up-to-date: auto-pairs
Already up-to-date: vim-surround
Already up-to-date: vim-github-hub
Already up-to-date: tpope-vim-abolish
Already up-to-date: vim-colors-plain
Already up-to-date: vim-dirvish-git
Already up-to-date: vim-peekaboo
Already up-to-date: vim-tmux-navigator
Already up-to-date: vim-lion
Already up-to-date: fzf.vim
Already up-to-date: vim-visual-star-search
Already up-to-date: vim-startify
Already up-to-date: ale
Already up-to-date: vim-speeddating
Already up-to-date: vim-mdx-js
Already up-to-date: vim-jsx-improve
Already up-to-date: vim-fugitive
Already up-to-date: yats.vim
Already up-to-date: vim-two-firewatch
Already up-to-date: ultisnips
Already up-to-date: loupe
Already up-to-date: vim-code-dark
Already up-to-date: vim-wakatime
Already up-to-date: vim-dirvish
Already up-to-date: critiq.vim
Already up-to-date: vim-gista
Already up-to-date: vim-gitgutter
Already up-to-date: vim-sensible
Already up-to-date: vim-matchup
Already up-to-date: goyo.vim
Already up-to-date: vim-grepper
Already up-to-date: vim-repeat
Already up-to-date: vim-commentary
Already up-to-date: vim-reason-plus
Already up-to-date: limelight.vim
Already up-to-date: vim-convert-color-to
Already up-to-date: vim-eunuch
Already up-to-date: fugitive-gitlab.vim
Already up-to-date: vim-deep-space
Already up-to-date: minpac
Already up-to-date: targets.vim
Already up-to-date: vim-rhubarb
Already up-to-date: undotree
client coc stopped!
Updated: coc.nvim
Already up-to-date: typewriter
Already up-to-date: vim-characterize
Already up-to-date: vim-projectionist
Already up-to-date: vim-apathy
Already up-to-date: terminus
Already up-to-date: rainbow_parentheses.vim
Already up-to-date: vim-fubitive
Already up-to-date: vim-scriptease
Already up-to-date: neco-vim
Already up-to-date: coc-neco
Already up-to-date: vim-polyglot
extension coc-css coc-rls coc-html coc-json coc-pyls coc-yaml coc-emoji coc-tsserver coc-ultisnips coc-highlight installed!
[coc.nvim] Source "emoji" recreated
[coc.nvim] Source "ultisnips" recreated
remote/host: python3 host registered plugins []
remote/host: generated rplugin manifest: /Users/ahmed/.local/share/nvim/rplugin.vim
All plugins are up to date. (Updated: 1, Newly installed: 0)
Press ENTER or type command to continue

[k-takata]

Hmm, looks okay.
What does happen when you execute call minpac#status() manually after PackUpdate?

[ahmedelgabri]

Ok, maybe we are not talking about the same thing? 🤔 I meant it used to show the commits of the updates etc...

pluginName - updated
16785 - commit message
16785 - commit message
16785 - commit message

pluginName2 - updated
16785 - commit message
16785 - commit message
16785 - commit message

[k-takata]

That's strange. I've never seen that before.

[ahmedelgabri]

@k-takata it was added in this PR, check the screenshot in this comment #58 (comment)

[k-takata]

I mean that I've never seen many same commit IDs are shown.

[ahmedelgabri]

That was just me showing an example, my bad I was lazy to change the commits sha :)

[k-takata]

So, what's the problem?

[ahmedelgabri]

It's not showing the commits of the updated plugins anymore

so it only shows this

pluginName - updated

pluginName2 - updated

not this

pluginName - updated
16785 - commit message
16785 - commit message
16785 - commit message

pluginName2 - updated
16785 - commit message
16785 - commit message
16785 - commit message

[k-takata]

Hmm, cannot reproduce. Does it happen with the all plugins?

[ahmedelgabri]

Yes with all plugins, this is how I load the plugins maybe you can see something I don't https://github.com/ahmedelgabri/dotfiles/blob/08b63a10d4e61cc446c9b88396251322efb7cbd5/files/.vim/autoload/plugins.vim

[k-takata]

This might not be related, but why you put these three lines inside a function?
https://github.com/ahmedelgabri/dotfiles/blob/08b63a10d4e61cc446c9b88396251322efb7cbd5/files/.vim/autoload/plugins.vim#L17-L19
They should be outside of functions.

[ahmedelgabri]

I guess it was just when I moved things inside a function that I just forgot to move it outside. But it was already working like this. So not sure if it's the issue or not, will move it out & see.

[k-takata]

Hmm, strange. Normally { doesn't need to be quoted on Windows.
Does msys2 do something special?

[matveyt]

Yeah, I finally found it. It's Cygwin issue, which also applies to all msys2 apps (i.e. linked to POSIX-ish layer msys-2.0.dll; mingw/native stuff is ok) due to the shared code base with Cygwin.

If Cygwin application is run directly (i.e. not by Cygwin/shell), the startup code tries to do "kinda shell wildcard globbing".

The CYGWIN environment variable:

(no)glob[:ignorecase] - if set, command line arguments containing UNIX-style file wildcard characters (brackets, braces, question mark, asterisk, escaped with ) are expanded into lists of files that match those wildcards. This is applicable only to programs run from non-Cygwin programs such as a CMD prompt. That means that this setting does not affect globbing operations for shells such as bash, sh, tcsh, zsh, etc. Default is set.

Also a relevant topic from StackOverflow: Cygwin's Git command is removing the curly braces from a command. How do I prevent this?

So that was just crazy: msys/vim runs minpac + msys/git without issues, but vim's official Windows binary fails to get any commit history. But let $MSYS='noglob' finally helps.

[ahmedelgabri]

Interesting find @matveyt, but for me, the issue is happening on a mac with zsh

[matveyt]

Yes, I already realized that it's a different story.

Just one debugging advice: if commit history is not shown, then it should be something about this piece of code invoking git log:

autoload/minpac/status.vim

let l:commits = minpac#impl#system([g:minpac#opt.git, '-C', l:dir, 'log',
        \ '--color=never', '--pretty=format:%h <<<<%D>>>> %s (%cr)', '--no-show-signature', 
'HEAD...HEAD@{1}'
        \ ])

You may try to set 'verbose':4 in minpac#init() and see what this command becomes exactly before execution. Then try to execute it manually, maybe it will be a hint.

[ahmedelgabri]

Thanks @matveyt, will do this & see

[ahmedelgabri]

Ok, so here is the output of one of these log commands

The command

git -C /Users/ahmed/.config/nvim/pack/minpac/start/coc-neco log --color=never --pretty=format:%h <<<<%D>>>> %s (%cr) --no-show-signature HEAD...HEAD@{1}

When I run it as is, I get

zsh: parse error near `<'

So I changed to notice the double quotes after format:

 git -C /Users/ahmed/.config/nvim/pack/minpac/start/coc-neco log --color=never --pretty=format:"%h <<<<%D>>>> %s (%cr)" --no-show-signature HEAD...HEAD@{1}

Which gave me

fatal: Log for 'HEAD' only has 1 entry.

That's because there is no HEAD@{1} when I cd into that directory & git log I can only see a single commit, so there is nothing to compare to. By checking the docs https://github.com/k-takata/minpac#minpacinitconfig the default value for Default clone depth is 1, so will change this and see. Although I didn't change my settings...

[matveyt]

In fact, I'm rather incompetent in all that git stuff, but from what I have learned so far, depth only cuts the history which precedes the cloning operation. However, minpac presently doesn't make use of it anyway.

HEAD...HEAD@{1} selects all the commits of the last local "head movement" (.git/logs/HEAD). And if we never committed anything into our local repository manually, then it's the last minpac#update(). But if a package was newly installed (cloned) yet never updated, then that list is empty, no matter what depth was.

Maybe it makes sense to add argument to minpac#status(), so we may choose to see, say, the last commit ('-1' option) instead of "the last update"?

[ahmedelgabri]

I was installing a new plugin today & it showed up, first time to see it since I opened this issue. So not sure what are the conditions in which this info will show up then? 🤔

[ahmedelgabri]

Turns out @matveyt was right here #76 (comment) & when I tested #76 (comment) I tested wrong.

The key is indeed this line

minpac/autoload/minpac/status.vim

Lines 27 to 29 in a4b9d29

	let l:commits = minpac#impl#system([g:minpac#opt.git, '-C', l:dir, 'log',
	\ '--color=never', '--pretty=format:%h <<<<%D>>>> %s (%cr)', '--no-show-signature', 'HEAD...HEAD@{1}'
	\ ])

And here is the proof

On the right is git from the command line running these commands & on the left the status view of minpac. I investigated this more & it seems that --depth might not be passed properly, the reason conjure is showing some info is that it's the only plugin I'm installing with a specific rev & that means that it has to checkout this revision which will mitigate any problems with any previous git commands & there will be proper history to log.

So @k-takata I think the problem might be with the syntax for --branch & --depth, they don't have = after them but actually a space, I tried to change this locally to

minpac/autoload/minpac/impl.vim

Lines 436 to 442 in a4b9d29

	let l:cmd = [g:minpac#opt.git, 'clone', '--quiet', l:url, l:dir, '--no-single-branch']
	if l:pluginfo.depth > 0 && l:pluginfo.rev ==# ''
	let l:cmd += ['--depth=' . l:pluginfo.depth]
	endif
	if l:pluginfo.branch !=# ''
	let l:cmd += ['--branch=' . l:pluginfo.branch]
	endif

@@ -435,10 +435,10 @@ function! s:update_single_plugin(name, force) abort
 
       let l:cmd = [g:minpac#opt.git, 'clone', '--quiet', l:url, l:dir, '--no-single-branch']
       if l:pluginfo.depth > 0 && l:pluginfo.rev ==# ''
-        let l:cmd += ['--depth=' . l:pluginfo.depth]
+        let l:cmd += ['--depth ' . l:pluginfo.depth]
       endif
       if l:pluginfo.branch !=# ''
-        let l:cmd += ['--branch=' . l:pluginfo.branch]
+        let l:cmd += ['--branch ' . l:pluginfo.branch]
       endif
     else
       " The type was changed (start <-> opt).

But it errors out with this, it seems that --depth 1 is passed as depth 1 instead & I'm not sure where exactly this is happening or why…

Updating (pull): auto-pairs
Updating (pull): vim-surround
Updating (pull): vim-dispatch
Updating (pull): vim-substrata
Cloning vim-sayonara
vim-sayonara: error: unknown option `depth 1'
vim-sayonara: usage: git clone [<options>] [--] <repo> [<dir>]
vim-sayonara:
vim-sayonara:     -v, --verbose         be more verbose
vim-sayonara:     -q, --quiet           be more quiet
vim-sayonara:     --progress            force progress reporting
vim-sayonara:     -n, --no-checkout     don't create a checkout
vim-sayonara:     --bare                create a bare repository
vim-sayonara:     --mirror              create a mirror repository (implies bare)
vim-sayonara:     -l, --local           to clone from a local repository
vim-sayonara:     --no-hardlinks        don't use local hardlinks, always copy
vim-sayonara:     -s, --shared          setup as shared repository
vim-sayonara:     --recursive[=<pathspec>]
vim-sayonara:                           initialize submodules in the clone
vim-sayonara:     --recurse-submodules[=<pathspec>]
vim-sayonara:                           initialize submodules in the clone
vim-sayonara:     -j, --jobs <n>        number of submodules cloned in parallel
vim-sayonara:     --template <template-directory>
vim-sayonara:                           directory from which templates will be used
vim-sayonara:     --reference <repo>    reference repository
vim-sayonara:     --reference-if-able <repo>
vim-sayonara:                           reference repository
vim-sayonara:     --dissociate          use --reference only while cloning
vim-sayonara:     -o, --origin <name>   use <name> instead of 'origin' to track upstream
vim-sayonara:     -b, --branch <branch>
vim-sayonara:                           checkout <branch> instead of the remote's HEAD
vim-sayonara:     -u, --upload-pack <path>
vim-sayonara:                           path to git-upload-pack on the remote
vim-sayonara:     --depth <depth>       create a shallow clone of that depth
vim-sayonara:     --shallow-since <time>
vim-sayonara:                           create a shallow clone since a specific time
vim-sayonara:     --shallow-exclude <revision>
vim-sayonara:                           deepen history of shallow clone, excluding rev
vim-sayonara:     --single-branch       clone only one branch, HEAD or --branch
vim-sayonara:     --no-tags             don't clone any tags, and make later fetches not to follow them
vim-sayonara:     --shallow-submodules  any cloned submodules will be shallow
vim-sayonara:     --separate-git-dir <gitdir>
vim-sayonara:                           separate git dir from working tree
vim-sayonara:     -c, --config <key=value>
vim-sayonara:                           set config inside the new repository
vim-sayonara:     --server-option <server-specific>
vim-sayonara:                           option to transmit
vim-sayonara:     -4, --ipv4            use IPv4 addresses only
vim-sayonara:     -6, --ipv6            use IPv6 addresses only
vim-sayonara:     --filter <args>       object filtering
vim-sayonara:     --remote-submodules   any cloned submodules will use their remote-tracking branch
vim-sayonara:
Error while updating "vim-sayonara".  Error code: 129

I'm keen to open a PR to fix this, but I need some help understanding why removing the = breaks everything & what is the proper fix then.

[ahmedelgabri]

Thanks to @kristijanhusak (sorry for the notification, you can unsubscribe from the thread if you want)

The issue was that I had this in my gitconfig

[pull]
  rebase = true

The fix is to add --rebase=false to the l:cmd here

minpac/autoload/minpac/impl.vim

Line 436 in a4b9d29

let l:cmd = [g:minpac#opt.git, 'clone', '--quiet', l:url, l:dir, '--no-single-branch']

But again, if I try to do that I get the same error as above & I'm not sure why. I wanted to port back the fix since I opened the issue. But I need some help to understand why it fails when I add the extra flag.

Check PR #88