feat: Do not delete working dir if git falls behind #5895
Conversation
This file contains hidden or 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
Signed-off-by: Luke Massa <lmassa@tripadvisor.com>
667863e to
acf0d9c
Compare
Signed-off-by: Luke Massa <lmassa@tripadvisor.com>
Signed-off-by: Luke Massa <lmassa@tripadvisor.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
what
If you go to run Clone() and you find the repo already exists but is not on the right ref, use git to get it to the right ref instead of doing a full re-clone.
why
Right now, when WorkingDir.Clone() is called, if the dir exists, it first checks to see if the ref the repo is on matches the one already determined by the relevant VCS's API as Head. If it's not, we do a forceClone, which deletes the directory and clones from scratch.
However, we know what ref we're trying to get to, so we should be able to use
git fetch && git reset --hardto simply move there.This should be a dramatic speedup, since we already likely have most of the git objects we need on disk. Additionally this is happening while holding a clone lock, so this should reduce contention.
tests
TODO: need to do some tests.
references
Is similar to #2921, but is not quite so ambitious.