alt.hn

2/14/2026 at 10:01:53 PM

Evolving Git for the Next Decade

https://lwn.net/SubscriberLink/1057561/bddc1e61152fadf6/

by AndrewDucker

2/15/2026 at 4:26:13 AM

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.

by thcipriani

2/15/2026 at 2:39:10 PM

Competition is good for an ecosystem.

by e40

2/15/2026 at 5:11:26 AM

> 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?

by dataflow

2/15/2026 at 6:53:22 AM

And also: why should he or git care?

by akkartik

2/15/2026 at 1:42:45 PM

GitLab pays his salary.

by kfjkfowlgkk

2/16/2026 at 6:47:52 AM

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.

[1] - https://learngitbranching.js.org/?locale=en_US

by alexhans

2/16/2026 at 9:55:21 AM

No, the problem isn't that Git exposes complexity. The problem is that Git exposes complexity through inappropriate terms, muddled concepts and bad documentation.

by ahartmetz

2/16/2026 at 10:08:29 AM

Fair enough. I think I'm trying to say the same thing you're saying. It's tough to navigate that world without a lot of investment in understanding the internals which, most people wouldn't do (rational behaviour for "yet another tool", if you don't come from a software development background).

by alexhans

2/15/2026 at 6:08:59 AM

Storing large files somewhere else is a step towards the centralized model. But it's against initial design principles of git.

by Panzerschrek

2/15/2026 at 3:45:12 PM

No it's not? It's simply an addressing model and interface. Sure you could use a fixed or centralised store but you could also use IPFS for example.

by OneDeuxTriSeiGo

2/15/2026 at 9:54:38 AM

Exacly. Git supposed to be DVCS not generic DVFS. Choose right tool for right task. I needed generic DVFS to store my docs, so I wrote one. Its easy and quick and does it job :)

by Borg3

2/15/2026 at 1:51:16 PM

As explained, the storage backend in git is pluggable but still not flexible enough.

There has been efforts to store git repos in torrents, and to store got repos on crypto blockchains, but all are big architectural challenges, for example people want everything to be backwards compatible for starters, and some want to be able to partially store some content somewhere else, while still keeping all existing use cases efficient.

by kfjkfowlgkk

2/15/2026 at 4:34:41 PM

The transition away from SHA1 is taking absurdly long. The hash function should have been more modular from the beginning.

by UltraSane

2/15/2026 at 10:08:58 AM

Git needs to track software licenses on a per commit basis.

by imtringued

2/15/2026 at 1:57:47 PM

No. Git should never do that, it would make git worse.

There are a lot of other different metadata that you could imagine to store per commit, but git already supports storing arbitrary data in every commit, you don’t need special casing for some type of metadata, just store it in the commmit as everyone already does, and perhaps build your own tools on top of that if you have special needs.

by kfjkfowlgkk

2/15/2026 at 10:59:07 AM

I don't fully understand what you mean, but you certainly don't want that in git. Git is a source code management system and that's all it should be. Any additional functionality should be added as an add-on (like git-annex) by extending its splendidly extensible replicated content addressed storage system.

by goku12

2/15/2026 at 8:48:10 PM

It's not even necessarily for source code. It can be for anything text-based. In that case, software licenses wouldn't even apply.

by Sophira

2/15/2026 at 2:13:55 PM

Use trailers like has become common for LLM assisted code.

Co-Authored-By: Whatever LLM

License: WTFPL

by veggieroll