Clone: Subtle Default Behaviour Difference Between libgit2 and git command line?

[falloutphil]

libgit2 behaviour is not identical in terms of fetching refs as part of the clone operation, when compared to the latest command line version of git.

Reproduction steps

Add some extra refs to your gitconfig, in my example I use bitbucket's pull requests which wouldn't be cloned or fetched by default:
remote.origin.fetch=+refs/pull-requests/*/merge:refs/remotes/origin/pr/*

Make sure you are using git command line version 2.25.1 or higher to show the expected behaviour (lower versions may work, version 2.17.1 does NOT work - it exhibits the same behaviour as libgit2).

If I then git clone into a repo I am able to git checkout the head commit of any PR without first doing a git fetch or git pull. This is fairly new behaviour in git.

If I try exactly the same thing with libgit2 (see below for attempts in Python and Guile) - the git checkout fails, just like older versions of the git command line do.

I'd expect both the command line and the library to leave the repository in exactly the same initial state after a clone.

Expected behavior

After cloning using libgit2 I should be able to immediately checkout the HEAD commit from any PR added to the refs in my gitconfig. For example using the git console command after doing the clone I get:

$ git clone ssh://git@foo:7999/foo/bar.git
Cloning into 'bar'...
remote: Counting objects: 101480, done.
remote: Compressing objects: 100% (30465/30465), done.
remote: Total 101480 (delta 75919), reused 94298 (delta 69833)
Receiving objects: 100% (101480/101480), 60.54 MiB | 18.26 MiB/s, done.
Resolving deltas: 100% (75919/75919), done.
$ cd bar
$ git checkout 7eb807f49a65b4c899e2718353d640943101d182
Note: switching to '7eb807f49a65b4c899e2718353d640943101d182'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 7eb807f49 Automatic merge

Actual behavior

Python:

import pygit2
callbacks = pygit2.RemoteCallbacks(credentials=pygit2.KeypairFromAgent("git"))
pygit2.clone_repository("ssh://git@foo:7999/foo/bar.git", "bar", callbacks=callbacks)

Guile:

(use-modules (git))
(libgit2-init!)
(clone "ssh://git@foo:7999/foo/bar.git" "bar"
       (make-clone-options
        #:fetch-options (make-fetch-options (%make-auth-ssh-agent))))

After running either of the libgit2 bindings above:

$ cd bar
$ git checkout 7eb807f49a65b4c899e2718353d640943101d182
fatal: reference is not a tree: 7eb807f49a65b4c899e2718353d640943101d182

Version of libgit2

1.3.0, also tested 1.1.0.

Operating system(s) tested

Linux (Ubuntu and Guix)

[ethomson]

Thanks for the report! It looks like git has dropped a new config option that we should probably honor.

[carlosmn]

Looks slightly related to #3361 as far as change of refspec matching rules goes.

[falloutphil]

Thanks for the report! It looks like git has dropped a new config option that we should probably honor.

Thanks for the reply @ethomson - can you elborate on the "new config option" you mention? What is this?

[ethomson]

Oh sorry, I think @carlosmn is right, I read the issue too quickly to understand it correctly.