omicron VS git-subrepo

> On my work I make 1-15 commits a day. If I have to spend thought cycles on the commit message, that is time that goes from other productive endeavours.

I make roughly that many commits a day as well. If something's easy to understand I'll put in a simple commit message (e.g. [1]), but I do put in the effort for more complicated ones.

[1] https://github.com/nextest-rs/nextest/commit/efd194b2e1d8d61...

[2] https://github.com/oxidecomputer/omicron/commit/b07a8f593325...

> I also wonder if internally Linux is used for development of the platform itself

Developers at Oxide work on whatever platform they'd like. I will say I am in the minority as a Windows user though, most are on some form of Unix.

> so they can create "virtual" racks to dogfood the product without full blown physical racks.

So one of the reasons why Rust is such an advantage for us is its strong cross-platform support: you can run a simulated version of the control plane on Mac, Linux, and Illumos, without a physical rack. The non-simulated version must run on Helios. [1]

That said we do have a rack in the office (literally named dogfood) that employees can use for various things if they wish.

1: https://github.com/oxidecomputer/omicron?tab=readme-ov-file#...

> I think the question is how well they can do the management plane.

Docs:

* https://docs.oxide.computer/api/guides/responses

See perhaps "This repo houses the work-in-progress Oxide Rack control plane."

* https://github.com/oxidecomputer/omicron

When we started the company, we knew it would be a three year build -- and indeed, our first product is in the final stages of development (i.e. EMC/safety certification). We have been very transparent about our progress along the way[0][1][2][3][4][5][6][7] -- and our software is essentially all open source, so you can follow along there as well.[8][9][10]

If you are asking "does anyone want a rack-scale computer?" the (short) answer is: yes, they do. The on-prem market has been woefully underserved -- and there are plenty of folks who are sick of Dell/HPE/VMware/Cisco, to say nothing of those who are public cloud borne and wondering if they should perhaps own some of their own compute rather than rent it all.

[0] https://oxide-and-friends.transistor.fm/episodes/holistic-bo...

[1] https://oxide-and-friends.transistor.fm/episodes/the-oxide-s...

[2] https://oxide-and-friends.transistor.fm/episodes/bringup-lab...

[3] https://oxide-and-friends.transistor.fm/episodes/more-tales-...

[4] https://oxide-and-friends.transistor.fm/episodes/another-lpc...

[5] https://oxide-and-friends.transistor.fm/episodes/the-pragmat...

[6] https://oxide-and-friends.transistor.fm/episodes/tales-from-...

[7] https://oxide-and-friends.transistor.fm/episodes/the-sidecar...

[8] https://github.com/oxidecomputer/omicron

[9] https://github.com/oxidecomputer/propolis

[10] https://github.com/oxidecomputer/hubris

Speaking of interesting names, their control plane is called Omicron: https://github.com/oxidecomputer/omicron

git-subrepo - complicated and difficult to understand

I find the following approach more consistent to manage components: https://github.com/ingydotnet/git-subrepo . And native package management systems, like npm in JavaScript universe, superior to either of the above. But the choice of a particular method depends on problems we need to solve. In terms of one-time codebase aggregation method they are all equally fine.

I much prefer https://github.com/ingydotnet/git-subrepo

Where I work we just package everything (nugets, python packages, npm) on our Artifactory. Contracts dependencies (DLLs, protobufs) are also distributed as packages. We made it easy to fetch and test the source and allow developers to develop, debug and test those dependencies with their own project if needed.

Every time we try to assemble repositories in macro-repos we always end up regretting it. Multiple dedicated repositories allow autonomy for teams and enforce modularity and coding as a library. Monorepos have a tendency of becoming huge merge trains easily and often derailed and with lots of fear of being blamed on stepping on someone else's toes.

We update often all our projects knowing full well that not doing so is just borrowing development time at high interest rate.

As a side-note when we do have to do an assembly of different code base, we use git-subrepo: https://github.com/ingydotnet/git-subrepo which provide the best of both submodules and subtree.

v2: I use git subrepo or a similar tool, to get the upstream yaml into my repo.

I found git-subrepo: https://github.com/ingydotnet/git-subrepo

You might also check out git subrepo.

Besides these git x-modules, there are historically three contenders:

git submodules: https://git-scm.com/book/en/v2/Git-Tools-Submodules

git subtrees: https://www.atlassian.com/git/tutorials/git-subtree

git subrepos: https://github.com/ingydotnet/git-subrepo

---

git subrepos work simply by copying your dependency to a subdirectory and committing the changes using one large commit that retains metadata about the update to the subrepo. For that reason, git subrepos aren't symlinks. You don't need to git clone --recursive like with git submodules, and you don't need cross-repo authentication. Updating a subrepo means performing another commit.

Even though git subrepos are the most poorly maintained, the design is simpler.

I wish someone would fork and take over maintenance.

git subrepos are the best.