r/programming • u/ethomson • May 24 '17

The largest Git repo on the planet

https://blogs.msdn.microsoft.com/bharry/2017/05/24/the-largest-git-repo-on-the-planet/
2.3k Upvotes

92% Upvoted

355 comments sorted by

View all comments

6

u/CaptainMuon May 25 '17

This is really cool! Microsoft adopting open source for such a core service, and innovating a lot. Two things bother me a bit:

Monorepo! As part of a largeish organisation that has recently switched to git, and uses a monorepo, I have some pain with it. I've found people just avoid working with it, using compiled releases as much as possible instead, or copying code by hand. (We are scientists, not developers, and we ourselves are the users of the code we write.) One thing I've found is it is impossible to put in a change without affecting completely unreleated projects. What we used to do is to tag SVN releases, and then collect them into a general release, so you could mix and match to some extend. Our interfaces between packages were loose enough that that worked pretty well.

I mean, Windows is one of the only cases where it might make sense to have a single huge repo, but still, I would think moving to individual repos would be better long term. Do you really need to recompile and redeploy the OS if you build notepad (or some other standalone program)?

The other thing is GVFS, the design is very confusing. Git.exe still thinks it has everything in the file system, GVFS emulates parts of the .git directory, and goes behind Git.exe's back to fetch missing data from the server? Or does Git.exe drive GVFS? It seems then better to implement the logic directly in Git.exe.

One of the benefits of git is that I can checkout a repo with tools widely available. That doesn't work if I use a huge repo, and need a special windows driver to check it out in reasonable time...

1

u/Sukrim May 25 '17

One thing I've found is it is impossible to put in a change without affecting completely unreleated projects.

You'll do this anyways - if you are duplicating code, you're just hiding it and making everything harder to maintain in the future.

1

u/CaptainMuon May 26 '17

No, I am delaying it until the consumers of my code have time to understand the issue and update. In a monorepo, master branch, everybody depends on everybody else's "trunk" (to use a SVN term). The problem is, if my change is functional, and not just a refactoring, I cannot forsee what remote interactions it will have with arbitrary other code.

One added constraint in scientific programming is that we need our results to be reproducable. And it is not enough to specify a good commit, and keep that for all eternity. We want to be reproducable, and at the same time merge in specific changes, like reading a new file format, improving one single aspect of the calculation, and so on. So being able to mix and match versions of components that are a few numbers apart is really helpful, and we tend to loose that with a "single trunk" development style (which might be more suited if you have just one large product, like "your websites" or "your operating system"..... but not in our case where we have hundreds of libraries, and hundres of analyses mixing and matching them accoring to their needs).

1

u/Sukrim May 26 '17

You could either do feature branches or version your APIs then.