Hacker News Reader

Comment by mlsu | Hacker News Reader

All software construction involves essential tasks, the fashioning of the complex conceptual structures that compose the abstract software entity, and accidental tasks, the representation of these abstract entities in programming languages and the mapping of these onto machine languages within space and speed constraints.

Git solves the deeply complex problem of distributed version control. Most complaints about git are actually complaints about the essential complexity of the problem, not the accidental complexity of the tool used to solve it.

View on HN

Totally agree that people spend way too much time complaining about git's solutions but there's not nearly enough criticism of the fact it's solving the wrong problem 99% of the time.

I want to share 5k LOC with a colleague. Anyone who thinks that requires a decentralised solution in 2023 is unwell.

I recently wasted a few hours because I forgot to fetch before running some code. Sure the UI could be better (if you're very tired and you're told you're up-to-date you'll stupidly believe it), but fundamentally the 'feature' that caused this problem is something I'll never use. I'm always going to code with a connection to the internet. I shouldn't need to mentally keep track of local vs remote because that distinction simply shouldn't exist.

What you fail to understand is that, outside of all talk about decentralization, keeping local state is a huge performance optimization. Tagging a large CVS tree used to take several minutes, because it would talk to the remote server separately about every file. History browsing & bisect are very pleasant in Git because the local computer already has all the information, and just needs to present it to you.

You can still cache things locally, it's just shouldn't be something the user has to be aware of. What I'm typing now isn't immediately being communicated to the central server every keystroke, there still is local state, but it's still a client-server architecture.

The repos I work on are often smaller than the average webpage, I'm really not buying the idea that in the age of HD streaming bandwidth-concerns are an issue here.

Incidentally none of the teams I've worked on ever even use any git features like bisect. The cult of git means everyone has to use git, even though for most people that just means many hours wasted googling with absolutely nothing to show for it (as in git is strictly inferior than just sharing files across a networked drive for many teams' use-cases).

Caching is trickier than decentralization because it's hard to know when the cache is valid. Fetch/push make that explicit, and not git's concern.

Meanwhile, others work in airplanes and in the woods.

Not using git bisect is your loss. I'm very happy it exists, and wouldn't trade git for just files on network drives.

Yes and pushing 'when do i update to/from the server' onto the user is exactly what I'm complaining about. No other software I use does this. Even software originally built to do things locally allows you to seamlessly update to/from a server nowadays (e.g. working on a cloud document in Word say). And any software built from the ground up to do this tends to have a great user experience (e.g. Figma).

You can absolutely build a system that fetches a git remote whenever it updates, you just need some sort of a notification/subscription system to know when to trigger it.

You can absolutely build a system that pushes (some of?) your branches on every commit.

For me personally, that'd be annoying; every time I talk to the git server, I want to insist on a Yubikey touch.

"History browsing & bisect are very pleasant in Git because the local computer already has all the information, and just needs to present it to you."

Probably the only thing that makes me not miss SVN too much.

Most complaints about git are about the design philosophy of the tool. While there are complex edge cases in distributed version control, the vast majority of situations people actually encounter are not that complex. But because git prioritizes the worst case over the typical case, it's much less usable than it could be.

Reply on news.ycombinator.com