You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think the expected behavior is to check out the ref specified by the parent repository. Come to think of it, "master" would be wrong even if it did exist.
Edit: just realized I said "checkouts" but the actual command was "submodule update --init --recursive"
The text was updated successfully, but these errors were encountered:
The default branch resp. ref should be determined by calling git symbolic-ref --short HEAD or by using git show-ref <ref> if used within the git checkout <ref> context. So if you are using a recent version of gitcache, there is no hard-coded "master" in it.
Can you check the output of the git symbolic-ref --short HEAD command?
I would like to recreate an example repo simulating your use case. I assume you have a repository with one or more submodules (which in turn have again submodules) and at least some of them are using LFS, right?
We have a repository with various branches, but none called "master". It looks like that branch name is getting added and causing checkouts to fail:
2023-11-09 09:59:08 Command 'C:\Users\afabian\AppData\Local\Programs\Git\cmd\git.exe -c lfs.storage=c:\gitcache\cache\mirrors\REPO_PATH\lfs lfs fetch origin master' failed with return code 2. Starting retry 2 of 3.
Invalid ref argument: [master]
I think the expected behavior is to check out the ref specified by the parent repository. Come to think of it, "master" would be wrong even if it did exist.
Edit: just realized I said "checkouts" but the actual command was "submodule update --init --recursive"
The text was updated successfully, but these errors were encountered: