@mhoye@mastodon.social To be more constructive here, I'll tell you a funnier story: a million years ago I worked on this git-predecessor called monotone (this is where the uniform merklized history idea emerged) and we *agonized* over the hashes-as-versions UI question. We were convinced it'd be the dealbreaker for almost everyone. Almost all the feedback we got was on that "nice ideas, but nobody is ever going to specify a version via a hash". We came up with all these different ways you could avoid it, all these UI affordances to use tags and local linear histories or abbreviations or whatever. And ultimately none of it mattered. The features (no central clocks, no locking or blocked commits, trivial branching, trivial full-repo replication, offline work) meant people just said "oh, well, fine" and used hashes. Basically all subsequent systems (mercurial, git, fossil) were built the same way. It became so normal that people even made systems with non-hash UUIDs present UI that _looks_ like hashes (eg. docker) just to meet the newly-reoriented UI expectation that "a version of a thing is a ~40 char string of hex noise". (IMO this is also why all the web3 stuff as well as secure p2p messaging like SSB and nostr had their moments when they did: elliptic curve crypto finally meant a public signing key could be "a ~32 char string of hex noise", which is actually a psychologically tolerable threshold in UI we hadn't previously identified, but is real. Dropping below the "full page of hex" RSA/DSA key-size mattered.)
Solving Git's Pain Points with Jujutsu (with Martin von Zweigbergk)
Git 3.0's upcoming SHA-256 default will be a costly mistake
Git 3.0 will make SHA-256 the new default content hashing algorithm and it will be an incomprehensibly expensive and ultimately valueless and avoidable global nightmare.
01 · Universal version control
We believe that simple, powerful, universal version control tools could help all kinds of creators produce better work.
Artifacts: versioned storage that speaks Git
Give your agents, developers, and automations a home for code and data. We’ve just launched Artifacts: Git-compatible versioned storage built for agents. Create tens of millions of repos, fork from any remote, and hand off a URL to any Git client.
Making Shell History Magical w/ Ellie Huxtable [Atuin] (TT #9)
Artifacts
Store, version, and share filesystem artifacts across Workers, APIs, and Git-compatible tools.
Gregory Szorc's Digital Home | High-level Problems with Git and How to Fix Them
When Git first came onto the scene in the mid 2000's, I was initially skeptical because of its horrible user interface. But once I learned it, I appreciated its speed and features - especially the ease at which you could create feature branches, merge, and even create commits offline (which was a big deal in the era when Subversion was the dominant version control tool in open source and you needed to speak with a server in order to commit code). When I started using Git day-to-day, it was such an obvious improvement over what I was using before (mainly Subversion and even CVS).
Commits and History - How Dialog Works
A guided tour of Dialog, a database for local-first software: facts, keys, the search tree, nodes, history, identity, sync and queries.
Git at any scale · Cursor
Hosting Git repositories at scale is a nightmare. When Linus Torvalds designed the first version of the information manager from hell (that's actually the tagline for Git, look it up), he had a very specific use case in mind: his own. He wanted to replace BitKeeper, the distributed version control system that was being used to develop the Linux Kernel. Of course, the replacement had to be distributed too. The Kernel is an unusual software project; it is extremely decentralized, with many different maintainers for its many different subsystems. A distributed version control system is a natural fit for this workflow.
A Categorical Theory of Patches
When working with distant collaborators on the same documents, one often uses a version control system, which is a program tracking the history of files and helping importing modifications brought by others as patches. The implementation of such a system requires to handle lots of situations depending on the operations performed by users on files, and it is thus difficult to ensure that all the corner cases have been correctly addressed. Here, instead of verifying the implementation of such a system, we adopt a complementary approach: we introduce a theoretical model, which is defined abstractly by the universal property that it should satisfy, and work out a concrete description of it. We begin by defining a category of files and patches, where the operation of merging the effect of two coinitial patches is defined by pushout. Since two patches can be incompatible, such a pushout does not necessarily exist in the category, which raises the question of which is the correct category to represent and manipulate files in conflicting state. We provide an answer by investigating the free completion of the category of files under finite colimits, and give an explicit description of this category: its objects are finite sets labeled by lines equipped with a transitive relation and morphisms are partial functions respecting labeling and relations.
Universal Version Control
Building tools to help people explore alternatives, keep track of history, and collaborate better, across all kinds of media.