> It is a binary file optimized for both space efficiency and quick access. Since then, it has been possible to create a repository that uses a reftable rather than the old file-based mechanism,

Good, are there (m)any other plans to ditch the slow files and use proper database? Or is it only reserved for various post-git competitors?

▲

cesarb 3 hours ago | parent | next [-]

> Good, are there (m)any other plans to ditch the slow files and use proper database?

The filesystem is a proper database, just not a relational one.

Linus focused heavily on performance when he wrote git; he used the filesystem because, as the main Linux kernel maintainer, he knew that the Linux VFS and filesystems were fast enough for these use cases.

(It's the use cases that have changed; it was not expected back then to have more than a few hundred refs in a single repository.)

	▲	eviks an hour ago \| parent \| next [-]
		> more than a few hundred refs Ah, yeah, "you're holding it wrong", though use cases haven't changed, it's closer to the expected common case of expectations turning out wildy wrong (Why would you ever expect people to stop NAMING things at scale???) But also the core property of the filesystem database has always been low performance for a bunch of tiny things
	▲	spankalee an hour ago \| parent \| prev [-]
		There are lots of places it'd be useful to use Git that don't have filesystems.

▲

112233 3 hours ago | parent | prev [-]

By "proper" I assume you mean relational? Or ACID? Or you mean using existing database software? What is so improper about the way git stores data?