undefined | Better HN

0 pointsblueflow1y ago0 comments

I'm maintaining a non-public mirror of some thousand OSS repositories. When you git clone, you do not use any "default branch", you clone the HEAD of the remote repository. This is a so-called "symbolic ref". People call it "default branch" because they don't know it can also point to a tag, a commit or be in the middle of an broken rebase. And you cannot set that information remotely via git. 'git push' can't do it, as it doesn't make sense for a bare repository.

So, if you have a git mirror in a private location that you need to push to, you get royally fucked in the arse by every project deciding to change their value for HEAD. These people basically broke 'git push' for my usecase.

So either they fix 'git push' to update the symrefs as well or shut up about using anything else than 'master'.

0 comments

superb_dev1y ago

Even if master was the default still, nothing changes about your problem. Repositories have always been free to choose whatever name they want and change it at any time.

Is the expected behavior when a remote changes its HEAD seriously just to break when you try to push?

blueflowOP1y ago

The HEAD value is not propagated by git operations (except for a fresh git clone). It is per-instance of a repository. If upstream changes, all other instances have to get fixed up manually.

You can't propagate (push/fetch will FAIL) a branch deletion to a repository if that branch is still referenced in the HEAD, and attempting to clone a repository where this has been forced will leave you in an empty directory with no checkout. This is the expected failure mode for all clones when a project changes to main and deletes master.

This is not specific to the main/master thing, it has always been a big pain, but with the main/master thing people started en masse to do it without technical necessity.

j / k navigate · click thread line to collapse