Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Cut down on data fetch from git dependencies #8363

Merged
merged 3 commits into from
Jun 18, 2020
Merged

Cut down on data fetch from git dependencies #8363

merged 3 commits into from
Jun 18, 2020

Commits on Jun 16, 2020

  1. Cut down on data fetch from git dependencies 

    Currently Cargo pretty heavily over-approximates data fetch for git
dependencies. For the index it fetches precisely one branch, but for all
other git dependencies Cargo will fetch all branches and all tags all
the time. In each of these situations, however, Cargo knows if one
branch is desired or if only one tag is desired.

This commit updates Cargo's fetching logic to plumb the desired
`GitReference` all the way down to `fetch`. In that one location we then
determine what to fetch. Namely if a branch or tag is explicitly
selected then we only fetch that one reference from the remote, cutting
down on the amount of traffic to the git remote.

Additionally a bugfix included here is that the GitHub fast path for
checking if a repository is up-to-date now works for non-`master`-based
branch dependencies.
    @alexcrichton
    alexcrichton committed Jun 16, 2020
    Configuration menu
    Copy the full SHA
    869642b View commit details
    Browse the repository at this point in the history

  2. Strip .git from urls on GitHub fast-path

    @alexcrichton
    alexcrichton committed Jun 16, 2020
    Configuration menu
    Copy the full SHA
    437e5d7 View commit details
    Browse the repository at this point in the history

  3. Update how locked git commits are fetched 

    This commit refactors various logic of the git source internals to
ensure that if we have a locked revision that we plumb the desired
branch/tag all the way through to the `fetch`. Previously we'd switch to
`Rev` very early on, but the fetching logic for `Rev` is very eager and
fetches too much, so instead we only resolve the locked revision later
on.

Internally this does some various refactoring to try to make various
bits and pieces of logic a bit easyer to grok, although it's still
perhaps not the cleanest implementation.
    @alexcrichton
    alexcrichton committed Jun 16, 2020
    Configuration menu
    Copy the full SHA
    ddc2799 View commit details
    Browse the repository at this point in the history