forge update - Unable to find revision in submodule path

[mits87]

Component

Forge

Have you ensured that all of these are up to date?

• Foundry
• Foundryup

What version of Foundry are you on?

0.2.0

What command(s) is the bug in?

forge update

Operating System

macOS (Apple Silicon)

Describe the bug

Hi there!

I've just started using foundry as a replacement of the hardhat (I really love the foundry idea ❤️ ).
I'm following the documentation and I realized that I have a small issue with forge update.

Basically I installed openzeppelin contracts:

forge install openzeppelin/openzeppelin-contracts

and if I execute a command forge update then I get an error:

Error:
fatal: Unable to find refs/remotes/origin/v4.8.0 revision in submodule path 'lib/openzeppelin-contracts'

The git submodule status returns:

 a24d813f6bd4ab40e07e8ba940dbbe9cca03f9cd lib/forge-std (v1.1.0-4-ga24d813)
 49c0e4370d0cc50ea6090709e3835a3091e33ee2 lib/openzeppelin-contracts (v4.8.0)

Any idea what I'm doing wrong?

[rkrasiuk]

@mattsse everybody seems to reference this as a solution. my best guess - conflicting submodules? v4.8.0 has also forge-std as dep

[rkrasiuk]

@mattsse after more investigation, i think the issue is the branch specification in the .gitmodules. some comments:

1. submodule set-branch only adds the entry in .gitmodules file, no additional magic behind the scenes. the submodule still points to the same commit at which it was added. stackoverflow
2. from the same stackoverflow answer: branch entry accepts branch name only. tags and shas are not supported.
3. some magical attempts to properly update submodules

[mattsse]

hmm, interesting, how do we fix this in the update command?

[rkrasiuk]

@mattsse didn't find a way to update the module without removing the branch entry in the .gitmodules

[mattsse]

this sounds very cursed. I think I introduced this by checkout out the latest semver tag.

[mds1]

how do we fix this in the update command?

perhaps forge update basically work by removing the old version and reinstalling the new version, instead of updating? I don't have anything concrete to repro, but I do this often cause sometimes updating doesn't work as expected. It's a bit clunky, but should work fine and be more robust

related, forge update should allow a tag/commit/branch to be specified when only updating one dep (this may be already supported, not sure)

[1-om]

I am getting this even without installing any libraries, i.e., in a new default project.

> forge update
Error: 
fatal: Unable to find refs/remotes/origin/v1.2.0 revision in submodule path 'lib/forge-std'

> git submodule status
 eb980e1d4f0e8173ec27da77297ae411840c8ccb lib/forge-std (v1.2.0)
 
> cd lib/forge-std
> git status
HEAD detached at v1.2.0
nothing to commit, working tree clean

[Genesis3800]

As of 29 Dec 2022, I am too facing this issue.
Cannot run forge update to update all dependencies, also cannot run forge update lib/openzeppelin-contracts to update particular dependency.

[AStox]

I'm also encountering this issue, and can reproduce it in a brand new forge project by running:

> forge init
> forge update
fatal: Needed a single revision
Unable to find current origin/v1.2.0 revision in submodule path 'lib/forge-std'

The workaround as of right now seems to be removing and reinstalling my submodules.

[0xMySt1c]

bump
running into this with open zeppelin
Unable to find refs/remotes/origin/v4.4.1 revision in submodule path 'lib/openzeppelin-contracts'

[mattsse]

rn forge update just does

git submodule update --init --remote

unclear what this error even means. I think this is somehow related to the git tag of the dependency but no idea honestly.

So not sure what to actually do on forge update

[RohanNero]

facing the same issue while following along here
cannot use forge update or forge update lib/solmate

[ZrowGz]

I removed the branch specification from within the .gitmodules file and it was able to update again. Unfortunately, this means it won't continue to track the version I started with, but I suppose this is just how it will have to be for now.

edit: Just had this issue crop up again on a new computer, found Option 3 on this site to be quite useful in resolving.

[phenix3443]

face same issue, git submodules should not do what package managers do.

[gosuto-inzasheru]

i think the only real solution to this is to keep a persistent branch for every tag/release in each submodule. that branch can then be specified in the .gitmodules file under branch = , eg branch = release/v1.6.0.

as noted before unfortunately the submodules functionality does not allow pinning to tags or commits.

for forge-std we could implement this ourselves, but for external dependencies it just depends on how they manage their branches, releases and tags.

[dkuppitz]

➜  forge update
fatal: Needed a single revision
Unable to find current origin/master revision in submodule path 'lib/erc4626-tests'
Failed to recurse into submodule path 'lib/openzeppelin-contracts-upgradeable'
Error: 
git submodule exited with code 1

OpenZeppelin has not specified a branch in the erc4626-tests submodule. erc4626-tests does not have a master branch, it's main. Seems like forge update simply assumes that no branch specification means master.

[ZrowGz]

➜  forge update
fatal: Needed a single revision
Unable to find current origin/master revision in submodule path 'lib/erc4626-tests'
Failed to recurse into submodule path 'lib/openzeppelin-contracts-upgradeable'
Error: 
git submodule exited with code 1

OpenZeppelin has not specified a branch in the erc4626-tests submodule. erc4626-tests does not have a master branch, it's main. Seems like forge update simply assumes that no branch specification means master.

I'd recently started getting this again too.

[zerosnacks]

Marking as duplicate of #7225 as it has a reproduction repo and identified the same issue

If this is not the case please leave a comment / re-open