How to fetch then checkout to a specific commit?

[Evian-Zhang]

I have read the source code of gix binary and cargo's integration, but I still can't figure out how to fetch then checkout to a specific commit.

As far as I know, If I want to fetch a repo at MY_URL to local path MY_PATH and checkout to specific commit COMMIT_HASH, the procedures are:

let repo = gix::init(&MY_PATH)
    .expect(&format!("Failed to initialize git repo at {MY_PATH:?}"));
let remote = repo
    .remote_at(MY_URL)
    .expect("Failed to create remote")
    .with_fetch_tags(gix::remote::fetch::Tags::None)
    .with_refspecs([COMMIT_HASH].into_iter(), gix::remote::Direction::Fetch)
    .expect("Unable to set remote");
let connection = remote
    .connect(gix::remote::Direction::Fetch)
    .expect("Failed to connect remote");
let outcome = connection
    .prepare_fetch(
        gix::progress::Discard,
        gix::remote::ref_map::Options::default(),
    )
    .expect("Failed to performance handshake")
    .with_shallow(gix::remote::fetch::Shallow::DepthAtRemote(
        std::num::NonZeroU32::new(1).unwrap(),
    ))
    .receive(gix::progress::Discard, &gix::interrupt::IS_INTERRUPTED)
    .expect("Failed to receive pack");

However, the generated git repo does not have any content in it.

[Byron]

The above would indeed fetch a specific commit for which a pack is fetched. Checking it out doesn't have an API yet, and cloning doesn't support setting the commit - it always checks out the current HEAD.
In theory, you could try to use a refspec like <HASH>:HEAD in an attempt to write to HEAD directly, but I think it refuses this as it's illegal both for git and for gix, thus you can't use gix::prepare_clone(…) for this either.

Maybe the easiest is to adapt the exclusive-checkout code that is used by the clone machinery to checkout a particular tree into a directory. Note that this needs exclusive access, and it unconditionally writes into the given directory. Proper checkouts like git checkout isn't implemented yet - that one would have to take care of not overwriting user changes for instance and a bunch of features are still missing to support that. You can follow the tracking ticket to stay informed about progress - it's actually something I am working on right now.