pygit2: fetch_refspecs implementation overrides destination refspec

[pmrowla]

          @pmrowla it seems it's breaking the Studio update (gto depends on the latest scmrepo). The symptom I see, is that we are getting: exp refs like:

2023-10-27 23:08:29,525 DEBUG scmrepo.git.backend.pygit2 fetch_refspecs: ['+refs/exps/72/31aed430fff6728c2057c6a5985a138725c70b/itchy-cham:refs/remotes/None/exps/72/31aed430fff6728c2057c6a5985a138725c70b/itchy-cham']

Mind the None part in the ref name.

It might be breaking some merge logic (when exp already exists locally). I can confirm that.

Originally posted by @shcheklein in #258 (comment)

[pmrowla]

we should not be overriding the refspec here:

https://github.com/iterative/scmrepo/blob/a2c78a13c39ddfe9b31500e5062ff720383d3412/src/scmrepo/git/backend/pygit2/__init__.py#L587-L600

(exp refs should never be fetched into the refs/remotes namespace)

[shcheklein]

exp refs should never be fetched into the refs/remotes namespace

curious, why did we have that logic in the first place? do you remember?

[shcheklein]

Also, 2cs - it's feel weird that get_remote(url) takes origin as url (that could be due to generalization across a few backend?), even more strange that it returns a remote w/o a name (even though name was provided to it). Should be it be called something else? get_anonymous_remote()? or should it be client who is anonymizing it if needed?

[pmrowla]

It was a pygit backend workaround from before we used the underlying anonymous remote functionality. Before we would create a temporary named remote. But even when we were generating the named remote we should not have been overriding the refspec (which was a bug)

The point of the get_remote function is to get an underlying libgit/pygit remote object needed for doing remote function calls and not necessarily a named "git remote"

[pmrowla]

The url parameter naming is a git convention, basically every remote operation in git can take either a direct url or the name of a remote like origin/upstream.