Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

For a close enough real life example, and very often just one file (PKGBUILD), ArchLinux uses one (orphaned) branch per package:

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).



That seems very weird. Do you happen to know the reasoning behind it?


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.


Orphan branches removes the (seldom-used, but still used) ability to commit on multiple microrepos at once.


Haha definitely!

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.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: