Plugin managers sometimes fail to update Conjure due to shallow clones

[roydsouza]

Errors:
fatal: Not possible to fast-forward, aborting.
a8686aa

NVIM v0.8.0-dev-737-g0b8bade49

(Was working till recently)

[Olical]

Ugh, not again. This happened last time I released. No force push, all I did was git merge --ff develop and git push. Why are plugin managers struggling with that?

And why has this started happening with recent releases despite my workflow not changing for years and years...

[Olical]

Original issue for this that I thought was over #404. So for some reason if I merge develop -> master and push now it breaks packer for people seemingly at random. I want to throw this over the fence and say it's an issue with Packer (which it really does feel like) but why is this not happening with every plugin? I don't think I'm doing anything special or wrong and haven't changed my behaviour in years (if ever since I started using git).

My theory is leaning towards Packer's optimisations clashing with specific git versions or repos, but that's a complete guess. I know it does shallow clones of some kind, maybe that's causing issues and can be turned off.

[Grazfather]

I've had this happen but in both this and #404 I tried to repro by checking out the mentioned commits and trying to re-update to no avail. I am inclined to agree it has something to do with the shallow clone. Maybe you can put a troubleshooting page somewhere to prevent new issues from being files all the time (Or keep some master issue opened until it's resolved).

[lockejan]

Same here again🙈

 ✗ Failed to update Olical/conjure
  Errors:
    fatal: Not possible to fast-forward, aborting.
    839fe23

Since a few days ago...

[adament]

I fixed this issue for me by unshallowing the repository:

cd ...\nvim-data\site\pack\packer\start\conjure
git fetch --unshallow

And then I could update conjure successfully using PackerSync. If I understand the git documentation correctly (and supported by wbthomason/packer.nvim#33) the repository only needs to be unshallowed once.

[gwerbin]

I just ran into this again trying to update from 488014 to f50d4d.

When I manually run git pull, I get fatal: refusing to merge unrelated histories.

My local history looks like this:

git log --show-linear-break --decorate --oneline --parents master origin/master

f50d4d 8002df 6546ac (tag: v4.50.0, origin/master, origin/develop, origin/HEAD) Merge branch 'austinmlv-guile-output' into develop
6546ac 1f43cf Add more Guile testing tools
1f43cf c6d775 Fix / improve localleader defaulting in the school
                    ..........
8002df 8ba9bb Fix / improve localleader defaulting in the school
                    ..........
c6d775 8ba9bb guile: append stray output to log
8ba9bb 423761 Prevent leaky tap-fns by using a defonce #550
423761 595b0c Rework tap code so it supports babashka + only one mapping and no options
595b0c aa0ec4 Add queue for tap values in clojure client
aa0ec4 (grafted) More python sandbox shenanigans
                    ..........
488014 (grafted, HEAD -> master) Correct janet stdio module form name

Looking at this history, I'm not sure how merging is ever supposed to work for grafted commits in a shallow repository, nor do I understand why it only seems to happen in some repos (like this one) and not in others. I thought I was pretty handy with Git, but this is far down along the "Git iceberg" and beneath the depths of my own knowledge. This might make for a good StackOverflow question if someone is able to craft a reproducible demo.

---

Edit:

I found this https://stackoverflow.com/q/41075972/2954547, and that's kind of a messy process, involving a full reset and clean. Are Packer, Paq, etc. actually doing that upon every update? It looks like they're supposed to be, if they aren't already.

This also doesn't address why it only seems to break sometimes. However I did manage to fix the issue by running the suggested commands:

git fetch --depth=1 origin
git switch master
git reset --hard origin/master
git clean -dfx

This seems like a reliable workaround.

Interestingly it left me with a different Git history, without any of the merge commits. It seems likely to me that the problem arises because Packer and Paq aren't executing this procedure for shallow clones, and in doing so are somehow causing this problem under the right circumstances.

[Olical]

Thank you for doing all of this research, I'm sure this'll come in handy! I still don't think I'm doing anything non-standard and I've definitely seen some other repos / plugins complaining about this same issue. So I'm not sure if it's down to how I merge PRs into develop then into master or if it's down to things like my gpg signed commits.

It's also deeper in the git iceberg than I feel comfortable with. If we can work out exact reproduction steps maybe we can take that to the plugin managers and slowly change how they update things.

If there's some git pattern I'm doing that is normally fine but causes this issue I can change my workflows to try and avoid it too, it's just a little annoying.