-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow use of sparse checkout when vendoring from git #400
Comments
Thanks for the issue. |
Yes, I'm suggesting using non-cone mode. Maybe it could be a flag to switch between cone mode and non-cone mode and don't try to infer it. Inferring could be too error prone and unnecessarily complex. If git doesn't infer it we shouldn't either. There are some gotchas but I think that doesn't apply here. I think sparse checkout without includes should not be accepted (eg shema-wise only allow declaration of sparse checkout when include or exclude are also set). |
I think we could allow this to be a flag-enabled behaviour and consider defaulting it eventually if it makes sense. @joaopapereira what do you think? |
Uses includePaths and excludePaths to configure non-cone sparse checkout for a git repo. Fixes carvel-dev#400 Signed-off-by: Zoltán Reegn <zoltan.reegn@gmail.com>
I gave it a shot, see PR. |
Sorry I dropped the ball on this but I have been busy lately. |
I'm not sure why to hide this functionality behind a flag, if it is supposed to be enabled only with a configuration key. Adding the key won't change anything for existing configurations, and users can enable the new behavior by adding the key to their configurations. As for the feature itself, I like the idea, it'll definitely help in some cases. But we need to make sure this doesn't affect caching of git repos we already have in place. |
I've checked the PR and ran some tests, which shown that even though the sparse checkout does improve the checkout command, there are more effective ways to speed up syncing of git sources. Vendir configuration:
Git configuration:
The last two options aren't available in vendir at the moment and can be potentially implemented. Test detailsHere are some combinations of flags and configuration options I tested. Base$ git init
$ git remote add origin git@github.com:something/something.git
$ time git fetch origin
remote: Enumerating objects: 833783, done.
remote: Counting objects: 100% (17084/17084), done.
remote: Compressing objects: 100% (6853/6853), done.
remote: Total 833783 (delta 10856), reused 15068 (delta 9320), pack-reused 816699 (from 1)
Receiving objects: 100% (833783/833783), 1.66 GiB | 10.56 MiB/s, done.
Resolving deltas: 100% (608199/608199), done.
From github.com:something/something
... skip many many branches and tags ...
git fetch origin 160.33s user 16.39s system 93% cpu 3:09.13 total
$ time git checkout main
branch 'main' set up to track 'origin/main'.
Already on 'main'
git checkout main 0.29s user 0.20s system 99% cpu 0.495 total
$ time git checkout some-branch
... skip ...
git checkout some-branch 0.48s user 0.21s system 100% cpu 0.698 total Fetching is slow, checkout is very fast. Sparse checkoutThe same as the base case, but with sparse checkout configuration set. $ git init
$ git remote add origin git@github.com:something/something.git
$ git sparse-checkout set --no-cone 'ci/**'
$ time git fetch origin
remote: Enumerating objects: 833783, done.
remote: Counting objects: 100% (17154/17154), done.
remote: Compressing objects: 100% (6896/6896), done.
remote: Total 833783 (delta 10922), reused 15089 (delta 9347), pack-reused 816629 (from 1)
Receiving objects: 100% (833783/833783), 1.66 GiB | 11.03 MiB/s, done.
Resolving deltas: 100% (608222/608222), done.
From github.com:something/something
... skip many many branches and tags ...
git fetch origin 165.51s user 16.36s system 99% cpu 3:03.42 total
$ time git checkout main
branch 'main' set up to track 'origin/main'.
Already on 'main'
git checkout main 0.04s user 0.00s system 98% cpu 0.041 total
$ time git checkout some-branch
... skip ...
git checkout some-branch 0.03s user 0.03s system 96% cpu 0.060 total Fetching is slow, checkout is ×10 times faster than in the base case, Fetch specific branchThe same as the base case, but fetching a particular branch. $ git init
$ git remote add origin git@github.com:something/something.git
$ time git fetch origin main
remote: Enumerating objects: 692145, done.
remote: Counting objects: 100% (67579/67579), done.
remote: Compressing objects: 100% (9598/9598), done.
remote: Total 692145 (delta 64168), reused 58331 (delta 57953), pack-reused 624566 (from 1)
Receiving objects: 100% (692145/692145), 1.63 GiB | 11.04 MiB/s, done.
Resolving deltas: 100% (526154/526154), done.
From github.com:something/something
* branch main -> FETCH_HEAD
* [new branch] main -> origin/main
git fetch origin main 162.29s user 15.93s system 100% cpu 2:57.28 total
$ time git checkout main
branch 'main' set up to track 'origin/main'.
Already on 'main'
git checkout main 0.30s user 0.19s system 98% cpu 0.505 total
$ time git checkout some-branch
... error, as the branch is not known ... Fetching is slow almost as in the base case, checkout is very fast. Use
|
Describe the problem/challenge you have
Vendoring from big repositories takes a long time currently. It would be great if that could be improved when using
includePath
andexcludePath
Describe the solution you'd like
When the user declares
includePath
orexcludePath
, and explicitly asks for a sparse checkout, perform a git sparse checkout for them usingincludePaths
andexcludePaths
(with globs you'd use no cone mode).Example new config:
Anything else you would like to add:
Vote on this request
This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.
👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"
We are also happy to receive and review Pull Requests if you want to help working on this issue.
The text was updated successfully, but these errors were encountered: