Conversation

K. Ryabitsev-Prime 🍁

We now publish tar'd up shallow git clones you can use with your CI. Please carefully read the safety caveats and use the script we provide to make sure you're not getting something malicious:

https://people.kernel.org/monsieuricon/using-shallow-git-tarballs-for-ci
2
22
21

@monsieuricon this is great! Thanks for the write up as well. This is something we might want to look at for Yocto (we could probably integrate the shallow tarball fetch & validation into our bitbake-setup command as an option).

0
0
1

@monsieuricon would it be better to follow this method instead?

eg.
- user issues git clone depth 1
- if it doesn’t exist in cache server, git goes thru normal path, otherwise serves the cache from https://www.kernel.org/pub/linux/kernel/shallow-tar/
- server can cleanup cache based on its own preferences (older than a month, space requirements, etc.)

1
0
0
@Logical_Error we can't reliably prebuild a "git clone --depth N" pack that git can use, for several reasons. For one, we can't know what the "N" value is going to be (some users will use --depth 5/10/50 just depending on how they are feeling that day); for two, on quickly moving repos like torvalds/linux.git, this would require a pack rebuild after each repo update.
1
0
0

@monsieuricon https://www.kernel.org/pub/linux/kernel/shallow-tar/ is when N == 1 tho right? i would assume it would make sense to only cache when N == 1 for `git clone` as well

also why prebuild instead of lazyloading (eg. cache only when a user requests)?

im just mainly curious why the kernel decided this path. i feel like transparently rerouting `git` to use the cache would be more effective than asking to use a separate mirror

1
0
0
@Logical_Error I'm not disagreeing, but... how would you lazy-cache an arbitrary pack? blobcatthink
1
0
0

@monsieuricon oh i have no idea… i was assuming that git had some sort of mechanism like that as it would help services like github/gitlab/codeberg etc

1
0
0
@Logical_Error Right... nothing in the standard git tooling, I'm afraid. It's possible that github and others are using some kind of clever hacking to do this, but, to my knowledge, there is no way to make git cache out packs generated on the fly.
0
0
1