> He said that GitLab hosts one repository with about 20-million references; each time a reference is deleted, the packed-refs file has to be completely rewritten which means rewriting 2GB of data. "To add insult to injury, this repository typically deletes references every couple seconds."
What in the world... why?
I would have loved to see some discussion of mono- versus poly-repos and steps towards improving this situation.
I prefer mono-repos personally, but they have the downside of being very busy and bulky because of that. Doing a partial clone by folder is very clunky at best, and there is no per-folder notion of permissions, which makes this a total non-starter for my team. The result is that we have thousands of repos and tooling that helps you check them all out into the correct place to make builds across them work. And inevitably they get out of sync and the builds break.
Git submodules seem like a solid approach, allowing you to cobble a bunch of poly-repos into something that kind of looks like a mono-repo, but the tooling support around it just makes it super painful, and you still don't have the ability to have an atomic commit across the repos. And people *hate* submodules.
I don't know the solution, but I wish this was on the radar of people who know git better than I. For now I'll just bumble through the repos I need to touch.
Storing large files somewhere else is a step towards the centralized model. But it's against initial design principles of git.
Git is a beautiful piece of software but it does expose complexity in a very by programmers for programmers kind of way.
I've successfully gotten many non tech roles to use git but there's usually a lot missed in the nuances and power that is in their reach, but not quite adopted.
The learn git branching site/game [1] has always been an awesome resource but you'd like something like that UX be almost part of the initial usage. Intuitive defaults, progressive learning at the right times, etc.
Nowadays, if you can get your users to use an agent CLI like Claude/Codex/OpenCode then it's easier to have that last experience but the more git itself uses accesible abstractions the easier it should be.
The transition away from SHA1 is taking absurdly long. The hash function should have been more modular from the beginning.
Git needs to track software licenses on a per commit basis.
Very excited for git 3.0, and also ready to be immediately frustrated by it :D
`jj` has done git users an amazing service simply by being a more intuitive VCS front-end is possible.