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

Cthulhu: Organizing Go Code in a Scalable Repo

blog.digitalocean.com

Post reply on HN
Print view View original

11–17 of 17 posts

Re: Cthulhu: Organizing Go Code in a Scalable Repo

#13

Post by jacques_chester »

donatj wrote: post #7

I understand the theory behind Monorepo but it always just rubs me the wrong way.

Once you realise that the reason you can't find the critical production code that's fritzing is because it's in another goddamn repo you didn't know about, you become a fan.

Having to reverse engineer CI/CD (or find someone who used to work on a project) to find where something came from is nuts. It should be as easy as search.

Re: Cthulhu: Organizing Go Code in a Scalable Repo

#14

Post by qznc »

vvvrrooomm wrote: post #10
qznc wrote: post #9

Earlier quoted context omitted.

I find them appealing because orchestrating lots of git repos is such a mess.

IMO the solution is git submodules. The problem with submodules mostly is the horrible workflow and the missing tool integration. Varying dependencies could result in separate parent repos that contain different subsets of submodules. A simple script can fix tooling: first commit the submodule changes then create the parent repo commit.

You don't want to create a commit in the parent repo all the time. If you fix a typo in a comment in a submodule, why commit anything to parent? Anyways, which parent, since there can be many. There should be more than one. Otherwise why use a submodule?

Another problem is that one forgets to update submodules when switching branches. Afaik git does not do this because of possible data loss in submodules?

I like submodules in general. They are great for dependencies where you want to follow more closely than release version. Still, it would be even easier in a monorepo. The main reason is probably that every anti-dependency is visible.

Post reply on HN