
Cthulhu: Organizing Go Code in a Scalable Repo - jsvcycling
https://blog.digitalocean.com/cthulhu-organizing-go-code-in-a-scalable-repo/
======
captaindiego
A little off-topic, but does anyone have any recommendations for methods for
managing 10s of git repos as various dependencies for wildly varying projects
as opposed to this sort of mono-repo approach? I've seen some organizations
try to use ivy, but never in a robust way.

------
allengeorge
Hmm. Sounds like “gta” is a reimplementation of “pants” or bazel (? - I’ve
never worked with bazel).

~~~
NightMKoder
I think they have a similar goal. The difference sounds like gta uses git for
change detection while bazel uses hashes to detect changes (hashes include the
hashes of the transitive closure of the deps; it’s a dag). The latter is more
robust in the face of noop edits that don’t change the output as well as
distributed caching of test/build results.

------
bovermyer
Nothing good can come of naming a project `cthulhu`.

~~~
Cthulhu_
oi

~~~
bovermyer
Note I said "project." How's R'lyeh these days?

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

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

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

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

------
al2o3cr
IA IA IF ERR != NIL FTAGHN

~~~
Cthulhu_
H̸̡̪̯ͨ͊̽̅̾̎Ȩ̬̩̾͛ͪ̈́̀́͘ C̷̙̲̝͖ͭ̏ͥͮ͟Oͮ͏̮̪̝͍M̲̖͊̒ͪͩͬ̚̚͜Ȇ̴̟̟͙̞ͩ͌͝S̨̥̫͎̭ͯ̿̔̀ͅ

