Hacker News Reader

Comment by im_down_w_otp | Hacker News Reader

I've come to learn that git monorepos are becoming quite popular. What I don't understand is why people are using git for this kind of workflow. It forces you to actively work against git's design goals and implementation. Which then compels the use of several odd workarounds and kludges to kind of seemingly reassemble a half-baked flavor of subversion. Why not just use a tool designed around monorepos and subtrees? I'm genuinely curious. I assume I'm missing something.

View on HN

The problem is that the alternatives are much, much worse.

There's nothing about the git/mercurial object models that makes them intrinsically inefficient with monorepos.

What's inefficient is materializing the object database (when cloning) and the working copy (when checking out), when you're only going to need tiny portions of them.

Subversion doesn't have the first problem (but comes with extremely slow history operations), but sparse checkouts don't really solve the second because you have to statically know what to filter.

A better direction is instead to virtualize the filesystem, so you get the semantics of a real monorepo with git/mercurial, and you fetch only what's actually needed without any change to your tooling (it just needs to interact with the filesystem). It's also very easy to transparently implement caching and prefetching this way.

This is the approach that Facebook and Microsoft took, and I believe Google too.

Though it is interesting that Microsoft's own efforts have been moving away from the virtual filesystem approach and back towards making sparse checkouts better/more reliable and better/more reliable support for partial checkouts (of history especially) and better memoization and caching of history reachability information (git commit-graph).

> It forces you to actively work against git's design goals and implementation.

It works against GitHub's design goals. You could work on multiple, logically distinct projects in the same git repository easily, if you so choose. git was designed for Linux's workflow.

> What I don't understand is why people are using git for this kind of workflow.

People like to use distributed workflows even with monorepos. E.g. chains of commits, branches, rewriting local history, etc.

It's clear that people want a mixture of monorepos with distributed workflows. There are two ways to get there: add distributed flows to a monorepos, or build a monorepo layer over a distributed tool.

Both seem like valid approaches. The market will decide which approach it prefers.

A big chunk of the industry joining in past decade has never seen/used anything but git, so it's the one hammer they have available.

Is that even a bad thing? If people are familiar with git --- its command syntax, its commit model, its collaboration setup --- why not let them keep using this model? Isn't it better for everyone if we put a few hundred people on targeted scalability fixes for git instead of making a few million people drop productive work and learn a new tool?

I mean, most of the people in industry today have known no character encoding except ASCII and its supersets --- and that's a good thing!

Git, while better now, it still allows people who are just familiar to shoot themselves in the foot.

So? It's the standard. Anything else starts with -1000 points. Something like hg might be better, but not better enough to be worth the cost of breaking uniformity in the industry.

I never get the footgun argument. If you need a gun, you're liable to shoot yourself. Programming in general is more and more accessible to wider audiences, but it hasn't become intrinsically easier.

What are these tools designed for monorepos and sub trees?

Probably the most popular one would be the "new hotness" that everyone used, or aspired to use, before git became popular, Subversion (https://subversion.apache.org/).

There are others that aren't free (e.g. Perforce) and some that aren't quite dedicated to the monorepos & subtree workflow, but which handle it better by design (e.g. Darcs, http://darcs.net/).

But, mostly I'm thinking of Subversion.

haha yeah, noones going to go back to subversion. The sum of the pain of the SVN problems solved by git is much larger than the slight pain of using git for a mono-repo.

The reason I would use a Git monorepo over Subversion is that Subversion is really painful to use. I would rather workarounds and kludges than that tire fire.

That was never my experience with Subversion, but YMMV.

Subversion on the server used with git-svn is bearable. Most of the advantages of git (local commits, rebasing, easy branching and merging) manifest themselves on the client-side.

The problem with using svn on the server is the lack of good tooling for things like code review. There's no SvnHub or SvnLab.

Perforce?

perforce helix core

No other DVCS is as popular. Git has a vast ecosystem of tools. No one wants to drop that.

Its certainly not against the design goals as official tooling supports shallow and sparse checkouts, they're just experimental features.

We should just strive forward and continue to make these features good.

Isn't git designed around the linux kernel repository, which is a monorepo?

I get the impression that things like LFS, submodule and subtree are hacks added onto git to try to make it behave like something it isn't.

Reply on news.ycombinator.com