RichiH / vcsh

config manager based on Git
GNU General Public License v2.0
2.17k stars 122 forks source link

vcsh clone fails to clone from a shallow repository #345

Open yacoob opened 1 week ago

yacoob commented 1 week ago

Steps to reproduce:

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.

alerque commented 1 week ago

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.