-
Notifications
You must be signed in to change notification settings - Fork 2.4k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Auto merge of #11840 - Byron:shallow-support, r=weihanglo
support for shallow clones and fetches with `gitoxide` This PR makes it possible to enable shallow clones and fetches for git dependencies and crate indices independently with the `-Zgitoxide=fetch,shallow_deps` and `-Zgitoxide=fetch,shallow_index` respectively. ### Tasks * [x] setup the shallow option when fetching, differentiated by 'registry' and 'git-dependency' * [x] validate registries are cloned shallowly *and* fetched shallowly * [x] validate git-dependencies are cloned shallowly *and* fetched shallowly * [x] a test to show what happens if a shallow index is opened with `git2` (*it can open it and fetch like normal, no issues*) * [x] assure that `git2` can safely operate on a shallow clone - we unshallow it beforehand, both for registries and git dependencies * [x] assure git-deps with revisions are handled correctly (they should just not be shallow, and they should unshallow themselves if they are) * [x] make sure shallow index clones aren't seen by older cargo's * [x] make sure shallow git dependency clones aren't seen by older cargo's * [x] shallow.lock test and more test-suite runs with shallow clones enabled for everything * [x] release new version of `gix` with full shallow support and use it here * [x] check why `shallow` files remain after unshallowing. Should they not rather be deleted if empty? - Yes, `git` does so as well, implemented [with this commit](GitoxideLabs/gitoxide@2cd5054) * ~~see if it can be avoided to ever unshallow an existing `-shallow` clone by using the right location from the start. If not, test that we can go `shallow->unshallow->shallow` without a hitch.~~ Cannot happen anymore as it can predict the final location perfectly. * [x] `Cargo.lock` files don't prevent shallow clones * [x] assure all other tests work with shallow cloning enabled (or fix the ones that don't with regression protection) * [x] can the 'split-brain' issue be solved for good? ### Review Notes * there is a chance of 'split brain' in git-dependencies as the logic for determining whether the clone/fetch is shallow is repeated in two places. This isn't the case for registries though. ### Notes * I am highlighting that this is the `gitoxide` version of shallow clones as the `git2` version [might soon be available](libgit2/libgit2#6396) as well. Having that would be good as it would ensure interoperability remains intact. * Maybe for when `git2` has been phased out, i.e. everything else is working, I think (unscientifically) there might be benefits in using worktrees for checkouts. Admittedly I don't know the history of why they weren't used in the first place. Also: `gitoxide` doesn't yet support local clones and might not have to if worktrees were used instead.
- Loading branch information
Showing
14 changed files
with
1,268 additions
and
298 deletions.
There are no files selected for viewing
Large diffs are not rendered by default.
Oops, something went wrong.
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
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
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
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
Oops, something went wrong.