Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Metahead – An enterprise-grade, Git-based metarepo

metahead.dev

Post reply on HN
Print view View original

31–38 of 38 posts

Re: Metahead – An enterprise-grade, Git-based metarepo

#31

Post by fuddle »

vlad_ivanov wrote: post #15
fuddle wrote: post #13

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 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'…

Thanks for the explanation, that helps a bit. I still think a video explainer would be helpful. :)

Re: Metahead – An enterprise-grade, Git-based metarepo

#32

Post by vlad_ivanov »

flir wrote: post #29
vlad_ivanov wrote: post #15

Earlier quoted context omitted.

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'…

It's... a materialized view? There's a great big ur-repo back there somewhere, and your tool provides multiple views into it? Hoenstly, that's a neat idea. No use to me, but a neat idea.

Yes it's exactly how you describe it

Re: Metahead – An enterprise-grade, Git-based metarepo

#33

Post by vlad_ivanov »

bananskalhalk wrote: post #30

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

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

Re: Metahead – An enterprise-grade, Git-based metarepo

#34

Post by vlad_ivanov »

wdb wrote: post #24

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

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

Re: Metahead – An enterprise-grade, Git-based metarepo

#35

Post by dayjaby »

vlad_ivanov wrote: post #33
bananskalhalk wrote: post #30

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

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" be…

Why invent a new word like "projection" though? Literally everyone would have understood "subrepo" just as fine.

How does your dependency management integrate into workflows? Last month I built a monorepo with all our repositories. For workflows it was essential that if a subrepo changed, not just this subrepo but also all its dependants get rebuilt.

I'm joining the waiting list to check for this :)

Re: Metahead – An enterprise-grade, Git-based metarepo

#37

Post by givel »

dayjaby wrote: post #35
vlad_ivanov wrote: post #33

Earlier quoted context omitted.

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" be…

Why invent a new word like "projection" though? Literally everyone would have understood "subrepo" just as fine. How does your dependency management integrate into workflows? Last month I built a monorepo with all our repositories. For workflows it was essential that if a subrepo changed, not just this subrepo but also all its dependants get rebuilt. I'm joining the waiting list to check for this :)

Regarding the word "projection", the thing is that you sync in multiple "sub"-repositories to the metarepo, but you can then recombine them dynamically from this repository. It's a projection as in it's a view, a slice of the metarepo that takes selected bits and combines them into an ad-hoc repository.

The metarepo contains a description of the relationship between those components (who contains whom), such that when you push to one of the contained, depended-on repositories, all the views that include it and as such depend on it get rebuilt.

Re: Metahead – An enterprise-grade, Git-based metarepo

#38

Post by btown »

rbetts wrote: post #26

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

Are there any other open-source solutions for this?
Post reply on HN