PackerUpdate "force" pull option

[axieax]

Describe the feature

Hi, it seems that sometimes plugins cannot be automatically updated with fast-forward, causing the update to fail. Reasons include conflicting changes as well as plugin authors rewriting history (which is often the case). Having another option to "force" push, i.e. reset local plugin repo state to be the same as the remote one, would mean that users don't have to manually find the corresponding local repo and reset the repo (git fetch origin && git reset --hard origin/$BRANCH), or temporarily uninstall and then install the plugin again from Packer's interface. Of course, this binding on the PackerUpdate window should display a warning that all local changes will be replaced.

[overcache]

I'm looking for a force options too. That's quit annoying to uninstall and install the plugin again

[adrubesh]

Also running into this, seems like two of my plugins had history rewrites and is breaking the PackerSync. I know, it's usually bad practice for plugin devs to push changes in this way but it would be a great option to force local packages to sync with origin.

[rickprice]

This has happened to me a bunch of times lately as well, would love a force option.

[dundargoc]

Wouldn't enabling rebase achieve this? That is, setting git option command to

    git = {
        subcommands = {
            update = 'pull --ff-only --progress --rebase',
        },
    }

[axieax]

Wouldn't enabling rebase achieve this? That is, setting git option command to

I just saw #381 which suggested using rebase, which still comes with its own disadvantages. A "force" option would ideally alleviate these many concerns.

Edit: also #327

[shazow]

Another failure mode is repos changing their default branch from master to main. I've found the most reliable way to "reset" failed updates is to rm -rf the plugin dir and let Packer clone it from scratch.

Perhaps a more extreme replace (on failure) option would be appropriate?

[Olical]

Many users of my plugin report this issue (https://github.com/Olical/conjure) but I never force push, ever. Are some repos just incompatible with shallow clones? If they unshallow my repo it works completely fine apparently, are others running into this with other plugins?

When people say "I have some plugins that have history issues and require force / re-cloning" I wonder if they're running into the same thing and don't realise. The first time this happened I was blamed as the maintainer for force pushing when I hadn't. This could be happening to many others.

[agorgl]

Yep happens to me with Olical/conjure plugin pretty often too!

[wavded]

I have to manually update nvim-tree weekly, would love to an option like this.

[gonzaloserrano]

@wavded same here, what does you upgrade process look like?

[wavded]

Right now its:

• Comment out nvim-tree use line in packer config
• Restart nvim
• Run :PackerSync to remove nvim-tree
• Uncomment nvim-tree use line in packer config
• Restart nvim
• Run :PackerSync to get latest version

I use their weekly version as well so I typically do this on Friday's. It's the only package I have to do it for. What do you do @gonzaloserrano ?

[gonzaloserrano]

Thanks! I had no idea how to fix it, I'm pretty new to the ecosystem.

[myarcana]

I have this error because I wrote some custom queries in my local version of treesitter ages ago and forgot about them, but it means packer is refusing to update treesitter. I just want to overwrite my local changes now. A simple :PackerUpdate! option would be extremely useful and convenient for simply resetting plugins to their fresh-install state.

 ✗ Failed to update nvim-treesitter/nvim-treesitter
  Errors:
    error: Your local changes to the following files would be overwritten by merge:
    	queries/scss/highlights.scm
    Please commit your changes or stash them before you merge.
    Aborting
    Updating 1897926..581e87b
    1897926

The error message should also at least give the directory of the offending plugin. I would have to take even more time to find out where the packer install directory even is, if not for the helpful comment-out :PackerSync tip above (although nvim-treesitter in particular can be a dependency of so many other things that this solution also isn't perfectly smooth sailing in this case).