It's good we now have (at least) Google, Facebook and Microsoft as examples of companies using monorepos. Those are names that carry some weight when thrown into a conversation.
It's good we now have (at least) Google, Facebook and Microsoft as examples of companies using monorepos. Those are names that carry some weight when thrown into a conversation.
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).
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.
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.
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.
My understanding of Google's monorepo is that search, mail, maps, etc. all live inside one repo.
[1] https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-g...
This basically sounds like CVS.
OTOH, I think the common CVS workflow actually matches the modern "we don't do stable branches" workflow a lot better than git does. Basically, if you had upstream CVS branches for more than released versions of software in maintenance mode you were doing it wrong.
I also tend to yearn for the days when I didn't spend 20% of my time rebasing and merging patches together, or rewritting dozens of patches worth of git history in order to move a couple minor commit hunks between patches for some reviewer. Or just juggling 20 different -next style remote repos.
Git is one of those tools that let you endlessly play with your tools rather than getting the job done.
I vehemently disagree with this sentiment. In fact, I find the opposite to be true. Git is the first VCS I used that is useful during coding instead of after it, when it's time to publish the final product, ie. a changeset. I can commit, merge, branch, rewrite and share changes freely and effortlessly whenever I need to without committing a bunch of crap to the shared repository that is of no interest to anyone.
After I'm finished getting shit done, I can then spend some time reviewing and thinking about the logical progression of changes so that the commit log will be readable to other people and older me. This is often just as valuable as writing the code itself.