packer.nvim
packer.nvim copied to clipboard
wbthomason
Failed to update
-
nvim --version: NVIM v0.5.0-dev+1260-ga6504ec33 Build type: Release LuaJIT 2.1.0-beta3 -
git --version: git version 2.30.1 (Apple Git-130) -
Operating system/version: macos Big Sur 11.3
-
Terminal name/version: alacritty 0.8.0 (a1b13e6)
Running :PackerUpdate seems to fail for packages. In this case 'p00f/nvim-ts-rainbow' is failing to update.
Hi @pedropmedina, this is very likely due to the fact that the main branch was rebased so the update command which involves pulling and merging with --no-ff will fail if the upstream branch is rebased. Ideally plugin authors wouldn't use rebase since people should ideally not rebase public branches others depend on but since it's a bit of an inevitability I'm currently working on #335 which should automate updating rebased branches.
Anyway till that is completed the 2 options are 1.) go to the plugin directory and pull with rebase=true or you can also change packers update command to use rebase=true keep in mind if you change packer's command this will mean you won't be able to inspect commits for your updates if you wanted to.
Hi, @akinsho this might be related to this issue or not but I just wanted to put it here in case it was. lsp-signature failed to update due to unrelated histories which is what's being worked on to fix this issue. However, the author did not rebase but had a different workflow which he kindly described in the mentioned issue.
https://github.com/ray-x/lsp_signature.nvim/issues/25
I'll quote the author's workflow here. It might be worth to test this workflow for the PR you're working on:
Did I run rebase recently? No.
What the hell I did? I run
git filter-branchandgit gc --prune=now --aggressiveto shrink the git repo size (save around 1MB after those commands)
@dhruvmanila thanks for digging in and pointing this out. After a little bit of googling it turns out that using git filter-branch has the same effect as rebasing since it essentially rewrites history (link) so the net result is the same for any plugin users and will hopefully be similarly fixed by my PR. I think across the board I see amongst my multitude of plugins quite a lot of history rewriting in various forms so just resetting hard to upstream in these cases should be a good catch all
I wanted to leave a comment to help people less familiar (like me) if they run into this issue.
Packer is syncing using git. If the sync fails, it's probably a git issue.
Go to the directory of the plugin. For me this is ~local/share/nvim/site/pack/packer/start/plugin-name.
Try a git pull. It should fail.
Run git status. If it show modified files, you have modified a plugin file and that's causing git pull to fail. Maybe you accidentally auto-formatted a plugin file? 😊
If that's the cause git stash and then git pull should work.
If you have not modified a file, it's likely as mentioned above that you can't git pull because the plugin author has done something (rebase) to their git repository to rewrite history. Run git pull --rebase and that should fix the issue.
Hopefully this helps someone!
Thanks for the pointers, @tom-on-the-internet! I'll also point out that packer should display a reason for failure if you press <cr> on the line of the failed item in the final results display window.
Thanks for the pointers, @tom-on-the-internet! I'll also point out that
packershould display a reason for failure if you press<cr>on the line of the failed item in the final results display window.
I had no idea <cr> let you see the error. So helpful. Thank you!
The reason most of the time is that the developer rebased master/main branch. Could we have an action to delete/reinstall it (as most of the time that's the easier way to deal with that issue?).
Here is a little script that should fix this particular problem (tested for Fedora 35) -> LINK I suggest using: USE-packer-package-repo-redirection-loop-fix.sh
P.S. I am open to suggestions for script improvements and related problems
I wanted to leave a comment to help people less familiar (like me) if they run into this issue.
Packer is syncing using git. If the sync fails, it's probably a git issue.
Hopefully this helps someone!
If you want to do this from ./packer/opt ./packer/start
for d in ./*/ ; do (cd "$d" && git stash); done
Ideally plugin authors wouldn't use rebase since people should ideally not rebase public branches others depend on but since it's a bit of an inevitability I'm currently working on https://github.com/wbthomason/packer.nvim/pull/335 which should automate updating rebased branches.
What's wrong with rebasing on master branch? Why does rebasing cause issues?
Makes local and upstream history diverge.
How come? If I have master/commit1 hash1 | localmaster/commit1 hash1
And I rebase on the repo master/commit2 hash2 | localmaster/commit hash1 master/commit1 hash1
Then what difference does it make to pull if it's rebase or merge? It will just see a new commit that it will pull.
I get different plugins erroring out intermittently failing to update and it's very annoying. When I examine the errors for the ones that fail, it's always:
Errors:
error: RPC failed; curl 26 .netrc parser error
fatal: expected flush after ref listing
4073f82
I do have a .netrc file but I regularly use that with curl on the command line and have no issues with it.
I just realized that I was using the .netrc format where everything is on a single line. On a whim, I changed it to the format where machine, login and password are on separate lines and ... no more intermittent failures to update! I ran PackerUpdate multiple times and it works great!
Just in case it helps anyone else.
Just had this issue with "nvim-colortils/colortils.nvim".
First I commented out the line of use "nvim-colortils/colortils.nvim" in my plugins / init lua file. Then issued :PackerClean... After that I reverted the line back to its original form to re-install the plugin fresh...
So basically I had packer to uninstall the plugin first and then install it once again fresh for me. Which worked cleanly.
Still getting this today after following the quickstart instructions.
The "error" is Already up to date
✗ Failed to update wbthomason/packer.nvim │~
Errors: │~
Already up-to-date. │~
usage: git submodule [--quiet] add [-b <branch>] [-f|--force]│~
or: git submodule [--quiet] status [--cached] [--recursive│~
or: git submodule [--quiet] init [--] [<path>...] │~
or: git submodule [--quiet] deinit [-f|--force] (--all| [-│~
or: git submodule [--quiet] update [--init] [--remote] [-N│~
or: git submodule [--quiet] summary [--cached|--files] [--│~
or: git submodule [--quiet] foreach [--recursive] <command│~
or: git submodule [--quiet] sync [--recursive] [--] [<path│~
1d0cf98 │~
✗ Failed to update nvim-lua/plenary.nvim │~
Errors: │~
Already up-to-date. │~
usage: git submodule [--quiet] add [-b <branch>] [-f|--force]│~
or: git submodule [--quiet] status [--cached] [--recursive│~
or: git submodule [--quiet] init [--] [<path>...] │~
or: git submodule [--quiet] deinit [-f|--force] (--all| [-│~
or: git submodule [--quiet] update [--init] [--remote] [-N│~
or: git submodule [--quiet] summary [--cached|--files] [--│~
or: git submodule [--quiet] foreach [--recursive] <command│~
or: git submodule [--quiet] sync [--recursive] [--] [<path│~
36aaceb │~
Still getting this today after following the quickstart instructions.
The "error" is
Already up to date✗ Failed to update wbthomason/packer.nvim │~ Errors: │~ Already up-to-date. │~ usage: git submodule [--quiet] add [-b <branch>] [-f|--force]│~ or: git submodule [--quiet] status [--cached] [--recursive│~ or: git submodule [--quiet] init [--] [<path>...] │~ or: git submodule [--quiet] deinit [-f|--force] (--all| [-│~ or: git submodule [--quiet] update [--init] [--remote] [-N│~ or: git submodule [--quiet] summary [--cached|--files] [--│~ or: git submodule [--quiet] foreach [--recursive] <command│~ or: git submodule [--quiet] sync [--recursive] [--] [<path│~ 1d0cf98 │~ ✗ Failed to update nvim-lua/plenary.nvim │~ Errors: │~ Already up-to-date. │~ usage: git submodule [--quiet] add [-b <branch>] [-f|--force]│~ or: git submodule [--quiet] status [--cached] [--recursive│~ or: git submodule [--quiet] init [--] [<path>...] │~ or: git submodule [--quiet] deinit [-f|--force] (--all| [-│~ or: git submodule [--quiet] update [--init] [--remote] [-N│~ or: git submodule [--quiet] summary [--cached|--files] [--│~ or: git submodule [--quiet] foreach [--recursive] <command│~ or: git submodule [--quiet] sync [--recursive] [--] [<path│~ 36aaceb │~
Same here
Still getting this today after following the quickstart instructions. The "error" is
Already up to date✗ Failed to update wbthomason/packer.nvim │~ Errors: │~ Already up-to-date. │~ usage: git submodule [--quiet] add [-b <branch>] [-f|--force]│~ or: git submodule [--quiet] status [--cached] [--recursive│~ or: git submodule [--quiet] init [--] [<path>...] │~ or: git submodule [--quiet] deinit [-f|--force] (--all| [-│~ or: git submodule [--quiet] update [--init] [--remote] [-N│~ or: git submodule [--quiet] summary [--cached|--files] [--│~ or: git submodule [--quiet] foreach [--recursive] <command│~ or: git submodule [--quiet] sync [--recursive] [--] [<path│~ 1d0cf98 │~ ✗ Failed to update nvim-lua/plenary.nvim │~ Errors: │~ Already up-to-date. │~ usage: git submodule [--quiet] add [-b <branch>] [-f|--force]│~ or: git submodule [--quiet] status [--cached] [--recursive│~ or: git submodule [--quiet] init [--] [<path>...] │~ or: git submodule [--quiet] deinit [-f|--force] (--all| [-│~ or: git submodule [--quiet] update [--init] [--remote] [-N│~ or: git submodule [--quiet] summary [--cached|--files] [--│~ or: git submodule [--quiet] foreach [--recursive] <command│~ or: git submodule [--quiet] sync [--recursive] [--] [<path│~ 36aaceb │~Same here
Same here +1
