Orphaned branches allows you to have multiple independent trees in the same git repo, si it's basically a way to stuff many "repos" (as in history) in a single one (as in object storage).
Arch maintainer here. Arch Linux doesn't use git, it uses svn still. Each arch package-repository (core, extra, community...) is a single SVN repository. Packages are split in subdirectories in that repository and checked out individually. Every maintainer deals with a few dozen packages individually, not the whole. There are seldom any commits that span multiple repositories.
What you were linked is the "svn to git" mirror which has to somehow translate that aspect of the setup to git.
Incidentally, the way Arch svn is currently set up works really well for arch devs and it is very hard to find a good replacement to it using git. Having a monorepo split up in lots of microrepos is straight up not possible in git.
> Having a monorepo split up in lots of microrepos is straight up not possible in git.
Not saying you should, but if your goal is to have a single repo (VCS) per repo (Arch) within which all packages are stored, and replicate the {core/{foo,bar,baz},extra/{qux,tor,meh}} tree, there could be many ways to do it depending on the exact needs, by leveraging GIT_DIR, GIT_WORK_TREE, GIT_OBJECT_DIRECTORY, GIT_ALTERNATE_OBJECT_DIRECTORIES, clone --single-branch and checkout --orphan.
Single monorepo with orphan branches, single clone, multiple work trees:
# create monorepo
mkdir core
cd core
git init --bare .git
export GIT_DIR=$(PWD)/.git
# add package in its own branch isolated
export GIT_WORK_TREE=$(PWD)/bash
mkdir bash
cd bash
git checkout --orphan bash
git add PKGBUILD
git commit
# switch package
export GIT_WORK_TREE=$(PWD)/readline
mkdir readline
cd readline
git checkout --orphan readline
git add PKGBUILD
git commit
# back to bash
export GIT_WORK_TREE=$(PWD)/bash
cd bash
git checkout bash
But each time you switch you have to switch the branch too since HEAD is in core/.git, so to work around that you can share the object dir.
Single monorepo with orphan branches, multiple clones but shared object dir, multiple work trees:
mkdir core
cd core
export GIT_OBJECT_DIRECTORY=$(PWD)/.git_objects
mkdir bash
cd bash
GIT_DIR=$(PWD)/.git git init # otherwise .git will be created next to .git_objects
git checkout --orphan bash
touch PKGBUILD
git add PKGBUILD
git commit -m "Add package: bash"
cd ..
mkdir readline
cd readline
GIT_DIR=$(PWD)/.git git init
git checkout --orphan readline
touch PKGBUILD
git add PKGBUILD
git commit -m "Add package: readline"
# back to bash
cd ../bash
git branch # just to check it's "bash", not "readline"
# clone existing package
cd ..
git clone some.where:core.git --single-branch --branch libarchive
cd libarchive
That's from the top of my head, and well it very much depends on what you want to achieve as a workflow.
That's a trade-off I'd be willing to make though given other advantages git offers. I wonder how mercurial would fare on that regard (possibly enhanced with a bespoke extension). Not that there's any reason for your tooling to change since it fits the bill so well :)
Anyway for archmac I went the boring way and stuffed everything as subdirs inside a single monorepo as I reckoned it'd just be easier for contributions. Definitely not the same scope as Arch Linux though.
FWIW there is a move towards git in Arch, which is happening slowly and I'm not sure what it'll end up looking like (probably 1 repo per pkgbuild on a custom git server, just like the AUR works right now). I was mostly talking about why svntogit looks the way it does :)
I often think about this issue of monorepos... git is such a wonderful tool, but the problems of subrepos and monorepos comes up so often it's surprising there isn't a definitive answer in git.
https://git.archlinux.org/svntogit/packages.git/refs
https://git.archlinux.org/svntogit/community.git/refs
Orphaned branches allows you to have multiple independent trees in the same git repo, si it's basically a way to stuff many "repos" (as in history) in a single one (as in object storage).