Restore the shallow clone behavior of the git walkers #4
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Resolves trustification#775 I finally figured out how to update the shallow clone, setting the fetch depth to `i32::MAX` to signal infinite fetch depth, per https://git-scm.com/docs/shallow I had wrongly assumed depth=0 signaled infinite depth -- it does for an initial clone, but not an update of a shallow one. Essentially, this improves the "day 0" experience -- the first walk of the shallow clone takes no more than a few minutes. But the annoying ~30 minute fetch is deferred to the first update of the shallow clone, effectively turning it into a deep clone, after which subsequent fetches are fast. I think that's a workable compromise until libgit2's perf issue is addressed. Signed-off-by: Jim Crossley <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves trustification#775
I finally figured out how to update the shallow clone, setting the fetch depth to
i32::MAXto signal infinite fetch depth, per https://git-scm.com/docs/shallowI had wrongly assumed depth=0 signaled infinite depth -- it does for an initial clone, but not an update of a shallow one.
Essentially, this improves the "day 0" experience -- the first walk of the shallow clone takes no more than a few minutes. But the annoying ~30 minute fetch is deferred to the first update of the shallow clone, effectively turning it into a deep clone, after which subsequent fetches are fast.
I think that's a workable compromise until libgit2's perf issue is addressed.