main branches locally

Posted Oct 23, 2025 19:06 UTC (Thu) by josh (subscriber, #17465)
In reply to: main branches locally by mathstuf
Parent article: Git considers SHA-256, Rust, LLMs, and more

> A single branch on the fork to serve as a "baseline" is useful.

But it *isn't* a baseline. Assuming I don't screw up and push to main by accident, all it does is provide a stale years-old snapshot of the upstream project's main branch (including its README), unrelated to any actual development going on in the repository.

> but having it not-exist introduces questions of what it means when your last feature branch is merged and you delete it. Is the `HEAD` ref resynced to keep the repository alive?

There's no fundamental reason a repository *couldn't* be kept alive with a virtual/fake/nonexistent HEAD. And to the extent forges don't support that, I'm frankly tempted sometimes to push a main branch containing a single empty commit, and make that HEAD. That's all independent of the metadata forges have showing what repository it was forked from.

to post comments

main branches locally

Posted Oct 24, 2025 1:38 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (3 responses)

That was the point of the following sentence:

> Forges could have an option to sync it automatically (a button, automatic, or scheduled),

I agree that it is annoying that it is not (often) synchronized. I typically only do so to make it easier to batch-delete already-merged branches on the remote (`git branch -a --merged` exists, but it is useful to have the "how far ahead/behind" view).

> There's no fundamental reason a repository *couldn't* be kept alive with a virtual/fake/nonexistent HEAD.

I guess my question is: what happens when you fetch from your fork in this state?

Forges do store repositories in a single object space and namespaced refs. I wonder if a symref can point between namespaces so that your fork's main is just a symref to the origin's main.

main branches locally

Posted Oct 24, 2025 23:26 UTC (Fri) by intgr (subscriber, #39733) [Link] (2 responses)

> I agree that it is annoying that [main branch] is not (often) synchronized

But why spend the compute resources updating the branch if users don't need or use it? Even if it were periodically updated, that would just create the illusion of an up to date branch. When I rebase, I want the latest origin/main, not "a few hours out of sync" one.

I might only use the fork for one pull request and never thereafter. Why even waste the disk space if there are no remaining feature branches?

As for "baseline state" of the fork: that's just the common ancestor of upstream repo and any particular feature branch.

I had never thought about these things but everything that gioele and Josh here said is a revelation about why git and the forges based on it feel so clunky to interact with.

main branches locally

Posted Oct 25, 2025 2:01 UTC (Sat) by mathstuf (subscriber, #69389) [Link] (1 responses)

> When I rebase, I want the latest origin/main, not "a few hours out of sync" one.

That's fine; why is your local `main` tracking your fork's `main` if you're not keep it up-to-date?

> I might only use the fork for one pull request and never thereafter. Why even waste the disk space if there are no remaining feature branches?

Forks live in the same repository as the main one. They are segregated using git namespaces (see `gitnamespaces(7)`) so that each access uses a different ref namespace and cannot "see" each other. This is the root cause of that issue where one could push a commit to a fork and then rewrite the URL to be that of the main repository and it would render your content under upstream's URL. I believe there is now a banner when this is done to show that the content is not actually "in" the repository being viewed when the object/tree/commit is not actually reachable from the project's ref namespace.

There was slight reference to this in it being "20 bytes on disk" elsewhere in this thread, but even that might be wrong (besides ref files being 40 bytes due to their ASCII representation) because I believe forges now use `reftable` to store refs in a single file (sqlite db?) rather than a file-per-ref due to filesystem overhead with that mechanism. The vast majority of the cost of a fork is in the database presence it takes up, not the git repository itself.

The shared-repository-with-namespaced-refs is also why I think some namespace-hopping symref to just make a fork's `main` *be* upstream's `main` would be an ideal solution here.

main branches locally

Posted Oct 25, 2025 3:03 UTC (Sat) by josh (subscriber, #17465) [Link]

> Forks live in the same repository as the main one. They are segregated using git namespaces (see `gitnamespaces(7)`) so that each access uses a different ref namespace and cannot "see" each other.

14 years ago, a friend and I wrote the first version of the git namespaces support. :)

This is very much what I had in mind when saying that there's no fundamental reason a fork "needs" a main branch, or a distinct main branch, in order to be tied to the original repository.

> I had never thought about these things but everything that gioele and Josh here said is a revelation about why git and the forges based on it feel so clunky to interact with.

❤️