Hacker News Reader

Comment by ChrisCinelli | Hacker News Reader

Managing dependencies and versions across repos is a pain. Refactoring across repos is quite hard when your code spreads across repos considering the tree of dependencies.

Unfortunately Git checkout all the code, including history, at once and it does not scale to big codebases.

The approach that Facebook chose with Mercurial seems a good compromise ( https://code.fb.com/core-data/scaling-mercurial-at-facebook/ )

View on HN

As mentioned in the post (which is from 2016), Google has also been experimenting with Mercurial as a frontend (in collaboration with "contributors from other companies that value the monolithic source model"). As an avid user of that experiment at Google, it's seems to be going very well.

I am not surprised. code.google.com used Mercurial. But I am still curious. Is Mercurial the frontend of Piper or it could live independently? What is open sourced and what is not?

Mercurial is used as a frontend to piper in that experiment. It doesn't live independently. Piper isn't open source.

Doesn't the Git Virtual File system that Microsoft is contributing to Git take care of this?

https://blogs.msdn.microsoft.com/devops/2017/02/03/announcin...

Edit: don't just down vote. If you have a problem with my comment, tell me why.

This currently only works on Windows, although they are planning OSX and Linux ports.

That is important. My link was back in 2017. Do you know of any ETA for GVFS getting on Linux?

I went to a talk earlier this year where they said they would do OSX before Linux. So it may be some time. There are design complexities in getting it to work, Windows has quite a different structure for filesystem drivers.

>> Unfortunately Git checkout all the code, including history, at once and it does not scale to big codebases

A shallow clone can be helpful in cases like this

Shallow clones have some significant limitations in terms of the operations that can be performed on the resultant shallow image. It used to be quite severe but many of the initial limitations have been lifted with improved implementations. Still shallow clones are tricky to do deep in the tree, but they are a potential option for huge repos.

Git works very well when the code is distributed. Which funnily enough is in the name. That we are using git as a centralized repository is a case of "Why do I need a screwdriver when I have a hammer?".

> Managing dependencies and versions across repos is a pain

There's nothing about git that requires you to use it like the kernel does. Centralized version control is just a special case of decentralized, if you're using git. You still get the benefits of your repo being a peer of the master repo, like local branches.

Reply on news.ycombinator.com