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
git clone --depth=1 https://github.com/yacoob/dotfiles /tmp/bootstrap
vcsh clone -b main file:///tmp/bootstrap
Normal git doesn't have a problem cloning from a shallow repository. vcsh fails to do so:
Initialized empty Git repository in /root/.config/vcsh/repo.d/bootstrap.git/
Switched to a new branch 'main'
remote: Enumerating objects: 63, done.
remote: Counting objects: 100% (63/63), done.
remote: Compressing objects: 100% (50/50), done.
remote: Total 63 (delta 0), reused 63 (delta 0), pack-reused 0
Unpacking objects: 100% (63/63), 20.02 KiB | 539.00 KiB/s, done.
error: Could not read ab41f5b88f9c170d167c1a44fa93159b9fa13ed1
fatal: Failed to traverse parents of commit 37cd7c6d313013a4e535a57a92a273a745224eee
error: file:///tmp/bootstrap did not send all necessary objects
fatal: Not a valid object name origin/main
merge: origin/main - not something we can merge
A shallow repository is often used in CI environments; my use case is running vcsh clone against a single-commit checkout inside a Github Action. My current workaround is to fetch the entire repository (fetch-depth: 0 in actions/checkout). This workaround is not feasible for a larger repository.
The text was updated successfully, but these errors were encountered:
VCSH is not actually doing a clone at all, it is initializing a repository of it's own, adding the source repository as a remote, fetching it, then doing a carefully crafted merge operation from the remote into it's own managed repo. This allows us to run hooks at various places and handle situations where files would otherwise be clobbered by a raw Git tooling.
I don't know if we can accommodate using a shallow repository as an upstream source because we actually need the history to sort out the merge operation. I'd be happy to facilitate a PR if somebody can figure how how to implement it, but I'm not in a position to work on it myself right now.
As an additional note I would question why you are using vcsh on a repository that is so big you can't handle having the history available. Not that is is wrong, it just sounds like there might be some better way to arrange this. VCSH was primarily intended for config files being overlayed on other directories, not heavy bulk data management.
Steps to reproduce:
Normal git doesn't have a problem cloning from a shallow repository. vcsh fails to do so:
A shallow repository is often used in CI environments; my use case is running
vcsh clone
against a single-commit checkout inside a Github Action. My current workaround is to fetch the entire repository (fetch-depth: 0
in actions/checkout). This workaround is not feasible for a larger repository.The text was updated successfully, but these errors were encountered: