Is it actually possible to do a shallow clone of a specific commit?

[decathorpe]

I'm currently trying to replace a "git" subprocess call with something equivalent from gix (to avoid a dependency on git, to avoid calling a separate program that may or may not be installed, for better error handling, etc.).

The git command I'm trying to replace is: git clone <url> <path> --revision <sha1> --depth 1 - essentially, (hopefully) do the minimum amount of work necessary to clone a repo at a specific ref.

Based on the gix documentation, this is what I came up with (the unwraps would get replaced with actual error handling once I get this working):

use gix::create::{Kind as CreateKind, Options as CreateOptions};
use gix::clone::PrepareFetch;
use gix::open::Options as OpenOptions;
use gix::progress::Discard;
use gix::remote::fetch::Shallow;

async fn gix_clone(url: String, sha1: String) -> Result<TempDir, Error> {
    let out = TempDir::new()?;
    let path = out.path().to_string_lossy();
    let path_str = path.to_string();

    tokio::task::spawn_blocking(|| -> Result<(), Error> {
        let mut pf = PrepareFetch::new(
            url,
            path_str,
            CreateKind::WithWorktree,
            CreateOptions::default(),
            OpenOptions::default(),
        )
        .unwrap()
        .with_shallow(Shallow::DepthAtRemote(NonZero::<u32>::MIN))
        .with_ref_name(Some(sha1).as_ref()).unwrap();

        pf.fetch_only(Discard, &AtomicBool::new(false)).unwrap();
        pf.persist();
        Ok(())
    }).await.unwrap()?;

    Ok(out)
}

However, this doesn't work. The documentation for PrepareFetch::with_ref_name (https://docs.rs/gix/0.76.0/gix/clone/struct.PrepareFetch.html#method.with_ref_name) says:

Note that name should be a partial name like main or feat/one, but can be a full ref name.

But this does not seem to be true - I get a panic from inside gix with the following expect message:

"we map by name only and have no object-id in refspec"

I have no idea what this error is supposed to tell me. The thing I'm passing to PrepareFetch::with_ref_name is a full commit hash. Looking at the code, that error message comes from a code branch under "Assure problems with custom branch names fail early" but I'm not passing a branch name, but a commit ref, and if util::find_custom_refname really does only validate branch names, it's kind of obvious that this would not work.

So ... is this a bug? Is the documentation wrong? Or am I just not doing this correctly?

[Byron]

Thanks for reaching out, and sorry for the hassle!

As a general note, if this is in any way supposed to land in something that is deployed OS-wide, i.e. would see every repository under the sun, then gitoxide probably isn't a good choice yet due to #1025. But if it only clones well-known repositories.

That aside, with_ref_name() really only wants a reference right now, but I also think that this is more of a shortcoming. The server seems to have responded with something that indicates it has the object, and it's just gix that doesn't know how to handle it.

A way to fix this would be to add a test for that, and then look at the server data to make it work. Finally, the with_ref_name() should probably change to support anything that a refspec supports (which naturally includes object hashes).

But there is clearly no simple solution to it, but let's see if Copilot can get a fix started.

[decathorpe]

Thanks for taking a look! And good to know about that limitation, then it probably makes sense to only introduce clone-with-gix as an option for people who don't want to call git as a subprocess.

Should I file an actual issue for the panic? I realized the error message is from an "expect" inside gix and not from one of my own "unwrap"s too late.

[Byron]

Glad I could help!

And thanks for offering! I'd love a PR that documents the panic for now instead of an issue, which should be about the same amount of effort for you while being an instant improvement that can eventually be fixed.

Besides that, here is a chance that this PR improves the situation beyond that, but I didn't take a look yet.

[decathorpe]

Good point - I've submitted #2315 for now.