Metahead – An enterprise-grade, Git-based metarepo

[fuddle]

As someone who's never heard of a metarepo before, I'm still not sure exactly what it is or why I should use it after reading their landing page. I think a metarepo explainer video would helpful.

[vlad_ivanov]

Vlad from metahead here. We answer this in the FAQ – metarepo is just a git repo that you can slice and dice any way you want while preserving history and having the ability to work on your part of the code. We went with "meta" because it's not exactly mono- or poly- – it's flexible enough so that you can make anything out of it. It also stores information about how your repos / projections relate – in that sense it's "meta" as well.

[umvi]

"metadata" is data that describes other data.

I would guess a "metarepo" is a repo that contains other repos.

Why would you want this? It's an alternative to monorepos or hacky homegrown solutions for managing related repos.

[iFire]

I am still really happy with using git subrepo as my metarepo https://github.com/ingydotnet/git-subrepo

[iFire]

The readme is understandable and the failure modes means it degrades to an ordinary git repo.

> This git command "clones" an external git repo into a subdirectory of your repo. Later on, upstream changes can be pulled in, and local changes can be pushed back. Simple.

[wdb]

One of the reasons to have a mono repo is to avoid the mirroring of PRs between repos. If you have 40+ repos and each time a package gets updated and you need to raise 39 PRs to bump the package. It's getting really old to do mirroring etc.

Not sure how this is an improvement over using a mono repo

[vlad_ivanov]

One thing to note is that we don't bump package versions but rather "mirror" the source code, so in that sense it works like a monorepo. But you're right that PR mirroring doesn't work beyond a certain point, and we certainly intend to scale beyond that in future

[edgyquant]

Not sure the implementation details but this

    $ git clone https://josh-project.dev/josh.git:/docs.git

Seems really neat to me

[rbetts]

> Maintaining an open-source library as part of your proprietary codebase? You can use metahead to publish and synchronise part of your code in its own public repo. Accept external contributions and check them against your internal usage of the library. You have the choice to make as much or as little as you want public, with file-granularity filters.

I've wished for this in multiple open-source oriented companies.

[btown]

Are there any other open-source solutions for this?

[bananskalhalk]

Looks cool, but I am unsure why I would use this instead of git scalar[0] with git submodule[1]?

[0]: https://git-scm.com/docs/scalar

[1]: https://git-scm.com/docs/gitsubmodules

[vlad_ivanov]

We will add a FAQ entry about scalar and we have one about submodules. But in short, here's why you might want to use this instead of the existing solutions:

* sub-repos -- projections as we call them -- are still a part of the one big history. But the history is filtered on your end and you only see relevant commits. You don't need to manually bump the version of projections * you could also get "one big history" behaviour with a traditional monorepo, but with projections you get benefits like fine-grained ACL

[kissgyorgy]

You lost me at "enterprise-grade".

[sgammon]

Hey Metahead. I wonder if you guys would be down to collaborate? We have a project that might plug in nicely. Let me know: [e-mail]

Or, feel free to drop a GitHub link?

[da39a3ee]

Sounds really interesting. I read the whitepaper; it was nice, but it's more like a technically-oriented setting-the-scene than a whitepaper.

[oooyay]

Git doesn't actually perform that well with monorepos of a certain scale and linear history. From what I read they're trying to give you a git interface to a monorepos that scales well.

[jauntywundrkind]

We're pretty worried about trying to monorepoize our existing code bases together.

How do we not break all the merge commits that link a project specific PR? Complex filter-branch I guess. How do we make GitHub able to actually help us navigate the past effectively?

It seems like we need some custom tooling to help us replay the past step by step across multiple repos, doing some rewriting as we go.

And what if it's not just your own repos one is managing? What if you also are trying to manage external deps too?

I see much validity to wanting good git-of-gits. Also if anyone has any suggestions for stitching together monorepos out of existing repos, please please comment!

[khazhoux]

Is that your reasoned conclusion after reading what this team actually built, and considering the deficiencies in today's repos + monorepos which led them to invent this new approach?

Or did you just read the headline?

[opentokix]

What the f is "Enterprise grade"?

[vosper]

There's no published pricing, just "contact sales", if you want SSO.

/s

[iFire]

MIT License

https://github.com/josh-project/josh/blob/master/LICENSE

[dang]

Can you please stop posting these? I'm sure your intention is good but anything as repetitive as https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... is off topic on HN.

You've also posted some good unpredictable comments so I definitely don't want to ban you. Basically, any form of predictability is what we're trying to avoid here.