[bug#49252] [PATCH] Channels defaulting to HEAD instead of ‘master’

[Kyle Meyer <kyle@kyleam.com>]

Ludovic Courtès writes:

> Oh, this must be the reason.  If I remove the cached clone:
>
>   rm -rf ~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq
>
> and then clone again, it works:

Great, glad that that mystery is solved.

> I suppose we need to add a call to fetch remote heads when they’re
> missing?  It seems that calling ‘remote-fetch’ is not enough.

Right, a fetch won't do it [1].  Users are free to delete or redirect
refs/remotes/<remote>/HEAD, and a fetch won't repopulate it.

On the command line, you can query the remote and recreate the symref
with `remote set-head <remote> -a':

  $ git symbolic-ref -d refs/remotes/origin/HEAD
  $ git symbolic-ref refs/remotes/origin/HEAD
  fatal: ref refs/remotes/origin/HEAD is not a symbolic ref
  $ git remote set-head origin -a
  origin/HEAD set to master
  $ git symbolic-ref refs/remotes/origin/HEAD
  refs/remotes/origin/master

In the libgit2 world, I think the most direct path might be something
along the lines of "get remote ref via git_remote_default_branch()"
followed by "create refs/remotes/<remote>/HEAD via
git_reference_symbolic_create()".  I'm not spotting either of those
functions in guile-git, though.

I haven't confirmed but based on the "symref-target" in the remote-ls
output you showed...

> --8<---------------cut here---------------start------------->8---
> scheme@(guile-user)> (define o (remote-lookup r "origin"))
> scheme@(guile-user)> (remote-connect o)
> scheme@(guile-user)> (remote-ls o)
> $13 = (#<<remote-head> local: 0 oid: #<oid 00000000742ebc4bc09ce69b970eceb78291bdbf> loid: #<oid 00000000742ebc4bc09ce69b970eceb78291bdbf> name: "HEAD" symref-target: 73408368> [...]

... I guess it might be possible to determine the ref target with
remote-ls.  In that case, it'd just be the
git_reference_symbolic_create() wrapper that was missing.


[1] In addition to the link I gave upthread, see
    <https://lore.kernel.org/git/20180601065121.GA15578@sigill.intra.peff.net/>
    for some discussion about whether fetch should populate it.