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](2cd5054b0a)
* ~~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](https://github.com/libgit2/libgit2/pull/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.
Build by PackageIdSpec, not name, to avoid ambiguity
### What does this PR try to resolve?
Fixes#11999
I previously added this code to ensure `cargo install` will build the intended package, but it turns out to cause ambiguity in the case where a package depends on prior versions of itself.
This ambiguity can be resolved by identifying the package to build by its pkg-spec, not name.
### How should we test and review this PR?
A test case is included.
I have additionally manually tested that, with this patch, the issue in #11999 is fixed and now installs correctly.
docs(registry): Further specify owner-remove response (#12056)
### What does this PR try to resolve?
This fixes a documentation issue as mentioned in #12056.
### How should we test and review this PR?
This is just a markdown file change, so it does not break anything.
### Additional information
Let me know if you have any changes or suggestions or how to write the tests for markdown files as well!
Thanks
Document that adding `#[non_exhaustive]` on existing items is breaking.
### What does this PR try to resolve?
Adding `#[non_exhaustive]` to an existing struct, enum, or variant is almost always a breaking change and requires a major version bump for semver purposes. This PR adds a section to the semver reference page that describes this and provides examples showing how `#[non_exhaustive]` can break code.
### Additional information
Adding `#[non_exhaustive]` to a unit struct currently has no effect on whether that struct can be constructed in downstream crates. This is inconsistent with the behavior of `#[non_exhaustive]` on unit enum variants, which may not be constructed outside their own crate. This might be due to a similar underlying cause as: https://github.com/rust-lang/rust/issues/78586
The confusing "variant is private" error messages for non-exhaustive unit and tuple variants are a known issue tracked in: https://github.com/rust-lang/rust/issues/82788
Checking for the struct portion of this semver rule is done in: https://github.com/obi1kenobi/cargo-semver-check/pull/4
Fix warning with unused mut
### What does this PR try to resolve?
```
warning: variable does not need to be mutable
--> src/cargo/core/compiler/unit_dependencies.rs:152:5
|
152 | mut state: &mut State<'_, '_>,
| ----^^^^^
| |
| help: remove this `mut`
|
= note: `#[warn(unused_mut)]` on by default
warning: `cargo` (lib) generated 1 warning (run `cargo fix --lib -p cargo` to apply 1 suggestion)
```
This is caused by https://github.com/rust-lang/rust/pull/110960
### How should we test and review this PR?
Running the mainline rust toolchain and `cargo build` without any wanrning messages would look like the above.
### Additional information
None
Doing so seems cleaner as there should be no logical difference between
shallow or not-shallow when fetching. We want a specific object, and should
get it with the refspec. `git` will assure we see all objects we need,
handling shallow-ness for us.
Note that one test needed adjustments due to the different mechanism used
when fetching local repositories, requiring more changes to properly 'break'
the submodule repo when `gitoxide` is used.
If there is a locked revision, it should substitue for git reference.
There is no chance that we will fallback to git reference when locked
revision exists.
It was misunderstood earlier and it's something we'd want as
it will quickly conclude that the remote didn't change compared
to a reference we would otherwise try to update.
feat: Add `-Zmsrv-policy` feature flag
### What does this PR try to resolve?
Nothing noticeable....
The intent is to unblock experiments with different compatible MSRV policies like
- #9930
- #10653
- #10903
While I normally don't like PRs that do nothing on their own, this at least allows any one of those efforts to move forward with different people without juggling these base commits for whoever is first to include in their PR
While there isn't an RFC for this yet, this is intended to allow us to experiment to get a better idea of what we should put in an RFC. In some cases, we first do an eRFC for this but I assumed this wouldn't be needed in this case as this builds on rust-lang/rfcs#2495 and, I'm assuming, will be more surgical in nature
### How should we test and review this PR?
The `Summary` changes are largely untested as they will be mostly tested through the future work that builds on this PR. However, I wasn't too concerned about that because the code is relatively trivial.
### Additional information
I chose the name `msrv-policy` to distinguish this unstable feature from `rust-version`. Though those appear in different places (`Cargo.toml` vs `-Z`), I can see them being confusing which was especially apparent when editing `unstable.md` which has an anchor for `rust-version`.
cargo-tree: Handle -e no-proc-macro when building the graph
### What does this PR try to resolve?
Makes `-e no-proc-macro` more useful when combined with `-i` or `-d`. Fixes#12030.
### How should we test and review this PR?
The new and existing tests should cover this, I hope!
### Additional information
Pruning proc-macro crates during graph construction is closer to how the edge-based filters work (`[no-]build` etc.), so even though `no-proc-macro` isn't technically filtering on edges, it's following a well-established code path.
