mirror clone does not keep HEAD updated

Hello all,

I'm testing `git clone --mirror` to properly mirror a repository on github.com. It appears to be working well, except for keeping HEAD correctly in place.

For example, here is what I did:

	$ git clone --mirror https://github.com/mvdan/test-repo
	$ cd test-repo
	$ git branch -a
	* main
	$ git log HEAD
	commit d1adda533e90692e02ae837233368fbcca2a0e49 (HEAD -> main)
	[...]

If I then go on the GitHub web UI to rename the default branch from "main" to "newmain", `git remote update --prune` sees that:

	$ git remote update --prune
	From https://github.com/mvdan/test-repo
	 - [deleted]         (none)     -> main
	 * [new branch]      newmain   -> newmain

However, HEAD stops working:

	$ git log HEAD
	fatal: your current branch 'main' does not have any commits yet

Am I holding the mirror wrong somehow? As far as the manpages say, `git remote update` should be enough to fully mirror all refs. And my understanding is that using HEAD is correct, that I do not need to use origin/HEAD like in a regular git clone.

I also tried what I would usually do to sync origin/HEAD in a regular git clone, but unsurprisingly, that does not work:

	$ git remote set-head origin -a
	error: Not a valid ref: refs/remotes/origin/newmain

Any pointers appreciated. Assuming I'm not missing anything obvious here, this might be a bug in `git remote udpate` for mirror clones.

Daniel Martí <mvdan@mvdan.cc> writes:

There is no such feature in "git clone" or "git fetch" to check what branch the remote HEAD is pointing at and move the local copy around. For a long time, even "git clone" did not have a reliable way to see where the HEAD at the remote site points at, and it used heuristics to guess what name to give to the first branch on the local side.

Modern versions of Git these days have a protocol level support to convey that information, and I think it is feasible to invent such a feature to automatically repoint refs/remotes/$remote/HEAD to whatever remote-tracking branch found in the refs/remotes/$remote/ hierarchy.

I do not think anybody is working on such a project, though.

We are pretty much "somebody should initiate the process to scratch their own itch, and we will help them in doing so" community, so you or somebody who reads this thread interesting will hopefully start such an effort ;-)

Thanks.

On Tue, Apr 4, 2023 at 12:07 PM Junio C Hamano <gitster@pobox.com> wrote:

Only because you didn't merge the patches I sent a while ago [1].

Or just repoint it to the remote's HEAD, which is what everyone expects.

That has not been my experience. Even when I scratch somebody else's itch, there is not much help, and the patches don't end up being merged.

Cheers.

[1] https://lore.kernel.org/git/20201118091219.3341585-1-felipe.contreras@gmail.com/

On Tue, Apr 4, 2023 at 11:35 AM Daniel Martí <mvdan@mvdan.cc> wrote:

Git does not set or update the remote HEAD, that's something the user is supposed to do (for some reason).

The only exception is when cloning a repository.

In my opinion this is completely unintuitive and unhelpful. 99.99% of the time I want the remote HEAD to be pointing to where the remote's HEAD is pointing to.

I implemented patches to fix that [1], but they were never merged.

It's particularly wrong when you are mirroring a repository, as in your case.

That's what I would expect, but that's not true.

I find that most of the time I need to read git's code to actually understand what it's supposed to do. I don't bother reading the documentation.

I've updated my old RFC patch adding tests and an option to make it work with mirrored repositories as well. With `fetch.updateHead=always` the mirrored clone always has the HEAD up-to-date.

Cheers.

[1] https://lore.kernel.org/git/20201118091219.3341585-1-felipe.contreras@gmail.com/ [2] https://lore.kernel.org/git/20230405012742.2452208-1-felipe.contreras@gmail.com/T/#ma012c4823814936a3ab8755d1d2b805d61b43133