Add --shared flag when using sparse checkout
#78
Conversation
| @@ -1,2 +1,3 @@ | |||
| *:lock | |||
| *.gem | |||
| Gemfile.lock | |||
There was a problem hiding this comment.
unrelated but we no longer need to track changes to this file since we removed it from Git
timsutton
changed the title
--shared flag when using sparse checkout
|
|
||
| clone_commands = ['git', 'clone', verbose ? '--verbose' : '--quiet'] | ||
| # For sparse checkouts, clone directly from the local mirror and skip the actual checkout process | ||
| # --shared is included so that the checkout remains fast even if the reference and destination directories |
There was a problem hiding this comment.
doc says this is a dangerous option which totally makes sense: https://git-scm.com/docs/git-clone#Documentation/git-clone.txt---shared
just to be suare that we have tested cases like deleting the checkout in the machine? yeah this is def only for CI usage only since we have clear idea on when and how to use these clones
There was a problem hiding this comment.
Yep. That's why initially I removed it in between the 1.6.0.pre1 -> 1.6.0 release because I wasn't going to keep it if it wasn't improving the checkout speed. But yeah, that's where when I tested locally on my Mac it wasn't the same situation as the disk/volume setup on the CI workers.
There was a problem hiding this comment.
I think there's potentially room to support more flags to augment or change the behavior of the sparse checkout, but I figure we should only add those if we've got a good reason
There was a problem hiding this comment.
100%, we should not allow caller to pass in any flags
| it 'should clone with verbose mode and --shared flag' do | ||
| subject.verbose = true | ||
| expect(subject).to receive(:fail_on_error).with( | ||
| 'git', 'clone', '--verbose', '--no-checkout', '--shared', '/cache', '/pwd/.', |
There was a problem hiding this comment.
i wonder with these new flags if the specs should include inspecting the cloned repo... for example we expect .git/objects/info/alternates to exists with --shared and not the case without --shared?
There was a problem hiding this comment.
Yeah – this work made me think that this repo could benefit from some simple integration tests which actually clones some simple repos and asserts for the expected state of the cloned repos.
There was a problem hiding this comment.
should be easy to write with AI
In an earlier test of the
--sparse-pathsfeature I had kept the--sharedflag to be used for the sparse checkout, but removed it because when testing on my local Mac it didn't seem to improve the speed.But, using
--sharedgreatly improves speed on systems where the reference Git clone is not the same as the destination checkout directory.--sharedcreates an "alternates" file at.git/objects/info/alternatesthat just contains a path that points back to the original reference repo location.Without
--shared, if Git can't use a shallow copy mechanism, it will make a full copy of the entire.gitdirectory contents from the reference clone, potentially taking minutes for a very large repo.