gitoxide integration: fetch

[Byron]

This PR is the first step towards resolving #1171.

In order to get there, we integrate gitoxide into cargo in such a way that one can control its usage in nightly via -Zgitoxide or Zgitoxide=<feature>[,featureN].

Planned features are:

• fetch - all fetches are done with gitxide (this PR)
• shallow_index - the crates index will be a shallow clone (planned)
• shallow_deps - git dependencies will be a shallow clone (planned)
• checkout - plain checkouts with gitoxide (planned)

The above list is a prediction and might change as we understand the requirements better.

Testing and Transitioning

By default, everything stays as is. However, relevant tests can be re-runwith gitoxide using

__CARGO_USE_GITOXIDE_INSTEAD_OF_GIT2=1 cargo test git

There are about 200 tests with 'git' in their name and I plan to enable them one by one. That way the costs for CI stay managable (my first measurement with one test was 2min 30s), while allowing to take one step at a time.

Custom tests shall be added once we realize that more coverage is needed.

That way we should be able to maintain running git2 and gitoxide side by side until we are willing to switch over to gitoxide entirely on stable cargo. Then turning on git2 might be a feature toggle for a while until we finally remove it from the codebase.

Please see the above paragraph as invitation for discussion, it's merely a basis to explore from and improve upon.

Tasks

• add feature toggle
• setup test system with one currently successful test
• implement fetch with gitoxide (MVP)
• fetch progress
• detect spurious errors
• enable as many git tests as possible (and ignore what's not possible)
• fix all git-related test failures (except for 1: built-in upload-pack, skipped for now)
• validate that all HTTP handle options that come from cargo specific values are passed to gitoxide
• a test to validate git2 code can handle crates-index clones created with gitoxide and vice-versa
• remove patches that enabled gitoxide enabled testing - it's not used anymore
• remove all TODOs and use crates-index version of git-repository The remaining 2 TODO's are more like questions for the reviewer.
• run all tests with gitoxide on the fastest platform as another parallel task
• switch to released version
• Tasks from first review round
• create a new gitoxide release and refer to the latest version from crates.io (instead of git-dependency)
• address 2nd review round comments

Postponed Tasks

I suggest to go breadth-first and implement the most valuable features first, and then aim for a broad replacement of git2. What's left is details and improved compatibility with the git2 implementation that will be required once gitoxide should become the default implementation on stable to complete the transition.

• built-in support for serving the file protocol (i.e. without using git). Simple cases like clone can probably be supported quickly, fetch needs more work though due to negotiation.
• SSH name fallbacks via a native (probably libssh (avoid LGPL) libssh2 based) transport. Look at this issue for some history.
• additional tasks from this tracking issue

Proposed Workflow

I am now using stacked git to keep commits meaningful during development. This will also mean that before reviews I will force-push a lot as changes will be bucketed into their respective commits.

Once review officially begins I will stop force-pushing and create small commits to address review comments. That way it should be easier to understand how things change over time.

Those review-comments can certainly be squashed into one commit before merging.

Please let me know if this is feasible or if there are other ways of working you prefer.

Development notes

• unrelated: this line refers to an issue that has since been resolved in curl.
• Additional tasks related to a correct fetch implementation are collected in this tracking issue. These affect how well the HTTP transport can be configured, needs work
• authentication is quite complex and centred around making SSH connections work. This feature is currently the weakest in gitoxide as it simply uses ssh (the program) and calls it a day. No authentication flows are supported there yet and the goal would be to match git there at least (which it might already do by just calling ssh). Needs investigation. Once en-par with git I think cargo can restart the whole fetch operation to try different user names like before.
  • the built-in ssh-program based transport can now understand permission-denied errors, but the capability isn't used after all since a builtin ssh transport is required.
• It would be possible to implement git::Progress and just ignore most of the calls, but that's known to be too slow as the implementation assumes a Progress::inc() call is as fast as an atomic increment and makes no attempt to reduce its calls to it.
• learning about a way to get custom traits in thiserror could make spurious error checks nicer and less error prone during maintenance. It's not a problem though.
• I am using RUSTFLAGS=--cfg to influence the entire build and unit-tests as environment variables didn't get through to the binary built and run for tests.

Questions

• The way gitoxide is configured the user has the opportunity to override these values using more specific git options, for example using url specific http settings. This looks like a feature to me, but if it's not gitoxide needs to provide a way to disable applying these overrides. Please let me know what's desired here - my preference is to allow overrides.
• gitoxide currently opens repositories similar to how git does which respects git specific environment variables. This might be a deviation from how it was before and can be turned off. My preference is to see it as a feature.

Prerequisite PRs

• make util::Progress thread-safe as prerequisite of #11448 #11602

[rustbot]

r? @epage

(rustbot has picked a reviewer for you, use r? to override)

[Byron]

Very early results for the MVP of fetch (a lot is missing, but it works already).

• 78s cargo (stable)
• 36s cargo (nightly) (2.2x faster)

And for additional reference:

• 32s git (2.4x faster)
• 31s gix (2.5x faster)

Measurements

Gix

❯ gix clone --bare https://github.com/rust-lang/crates.io-index  crates-index
 14:36:44 read pack done 299.8MB in 27.80s (10.8MB/s)
 14:36:44  indexing 928260 objects were resolved into 464130 objects during thin-pack resolution
 14:36:44  indexing done 464.1k objects in 27.75s (16.7k objects/s)
 14:36:44 decompressing done 1.6GB in 27.75s (57.0MB/s)
 14:36:47     Resolving done 464.1k objects in 2.54s (183.1k objects/s)
 14:36:47      Decoding done 17.0GB in 2.54s (6.7GB/s)
 14:36:47 writing index file done 13.0MB in 0.02s (748.1MB/s)
 14:36:47  create index file done 464.1k objects in 30.36s (15.3k objects/s)
+refs/heads/*:refs/remotes/origin/*
        a44803046c31473544456b8d9ea089a868da2691 refs/heads/master -> refs/remotes/origin/master [new]

prodash ( main) [$?] took 31s

cargo (stable)

❯ cargo fetch
warning: file found to be present in multiple build targets: /Users/byron/dev/github.com/Byron/prodash/examples/dashboard.rs
    Updating crates.io index

prodash ( main) [$?] took 1m18s

git

❯ git clone --bare https://github.com/rust-lang/crates.io-index  crates-index
Cloning into bare repository 'crates-index'...
remote: Enumerating objects: 464130, done.
remote: Counting objects: 100% (55/55), done.
remote: Compressing objects: 100% (55/55), done.
remote: Total 464130 (delta 29), reused 26 (delta 0), pack-reused 464075
Receiving objects: 100% (464130/464130), 285.87 MiB | 11.45 MiB/s, done.
Resolving deltas: 100% (320065/320065), done.

prodash ( main) [$?] took 32s

cargo (nightly)

❯ /Users/byron/dev/github.com/rust-lang/cargo/target/release/cargo -Z gitoxide=fetch fetch
warning: file found to be present in multiple build targets: /Users/byron/dev/github.com/Byron/prodash/examples/dashboard.rs
    Updating crates.io index

prodash ( main) [$?] took 36s

[bors]

☔ The latest upstream changes (presumably #10771) made this pull request unmergeable. Please resolve the merge conflicts.

[weihanglo]

This is soon to be merged. @Byron wrote a decent commit message cfffda9, calling out important stuff to follow up. Let me repost them here:

Limitations

Note that what follows are current shortcomings that will be addressed in future PRs.

• it's likely that authentication around the ssh protocol will work differently in practice
  as it uses the ssh program.
• clones from file:// based crates indices will need the git binary to serve the locatl repository.
• the progress bar shown when fetching doesn't work like the orgiinal, but should already feel 'faster'.

One thing also needs attentions is the behavior change of git credential helper mentioned in #11448 (comment). -Zgitoxide follows what git CLI does, but it is better mentioning the change when calling for testing.

Thank you to everyone involved in this pull request!

@bors r+

[bors]

📌 Commit cfffda9 has been approved by weihanglo

It is now in the queue for this repository.

[bors]

⌛ Testing commit cfffda9 with merge 7cba527...

[bors]

☀️ Test successful - checks-actions
Approved by: weihanglo
Pushing 7cba527 to master...