Skip to content

Comment on Why Git Ain’t Better Than Xparent

Comments

I've heard of this scenario before, but don't understand this situation. What possible technical reason would justify a billion lines of code needing to be in one repository? If it's a matter of history, perhaps we just need a better import tool.

A company with a couple of applications will likely have a dozen or more shared libraries or other resources.

You could create a repository for each resource, but resources are merged and split over time, a change in a resource may require application changes as well, etc.

All in all it is often just simpler to make a nice directory structure and treat it as one repository rather than deal with dozens of repositories.

I have sort of this problem myself, I have 20 or so shared frameworks in my “big repository” where I would like to release a few of them as F/OSS, but I am using Git and it is too much of a hassle for me needing to then put these frameworks in their own repositories.

Git submodules pretty much solve this problem in many cases.

But not in the case explained.

Git submodules not only are still separate repositories (making merging and splitting the shared resources problematic) they also require maintenance in the repository they are added to, so in practice a symbolic link is much simpler (as you do not need to update that link each time the submodule is updated).

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.