We've raised $17M to build what comes after Git

If you're being handed millions of dollars in early venture capital and don't have revenue/pmf to show, they're going to want to see a top university, FAANG, relevant industry experience, etc. How else would they underwrite the risk?

Team matters. What other proxies are there?

I started using Git around 2008, if memory serves. I have made myself more than familiar with the data model and the "plumbing" layer as they call it, but it was only a year ago -- after more than two decades of using Git, in retrospect -- that a realisation started downing on me that most folks probably have a much easier time with Git than I do, _due_ to them not caring as much about how it works _or_ they just trust the porcelain layer and ignore how "the sausage is made". For me it was always either-or situation -- I still don't trust the high-level switches I discover trawling Git's manpages, unless I understand what the effect is on the _data_ (_my_ data). Conversely, I am very surgical with Git treating it as a RISC processor -- most often at the cost of development velocity, for that reason. It's started to bug me really bad as in my latest employment I am expected to commit things throughout the day, but my way of working just doesn't align with that it seems. I frequently switch context between features or even projects (unrelated to one another by Git), and when someone looks at me waiting for an answer why it takes half a day to create 5 commits I look back at them with the same puzzled look they give me. Neither of us is satisfied. I spend most of the development time _designing_ a feature, then I implement it and occasionally it proves to be a dead-end so everything needs to be scrapped or stashed "for parts", rinse, repeat. At the end of the road developing a feature I often end up with a bunch of unrelated changes -- especially if it's a neglected code base, which isn't out of ordinary in my place of work unfortunately. The unrelated changes must be dealt with, so I am sitting there with diff hunks trying to decide which ones to include, occasionally resorting to hunk _editing_ even. There's a lot of stashing, too. Rebasing is the least of my problems, incidentally (someone said rebasing is hard on Git users), because I know what it is supposed to do (for me), so I deal with it head on and just reduce the whole thing to a series of simpler merge conflict resolution problems.

But even with all the Git tooling under my belt, I seem to have all but concluded that Git's simplicity is its biggest strength but also not a small weakness. I wish I didn't have to account for the fact that Git stores snapshots (trees), after all -- _not_ patch-files it shows or differences between the former. Rebasing creates copies or near-copies and it's impossible to isolate features from the timeline their development intertwines with. Changes in Git aren't commutative, so when my human brain naively things I could "pick" features A, B, and C for my next release, ideally with bugfixes D, E and F too, Git just wants me a single commit, except that the features and/or bugfixes may not all neatly lie along a single shared ancestral stem, so either merging is non-trivial (divergence of content compounded with time) or I solve it by assembling the tree _manually_ and using `git commit-tree` to just not have to deal with the more esoteric merge strategies. All these things _do_ tell me there is something "beyond Git" but it's just intuition, so maybe I am just stupid (or too stupid for Git)?

I started looking at [Pijul](https://pijul.org/) a while ago, but I feel like a weirdo who found a weird thing noone is ever going to adopt because it's well, weird. I thought relying on a "theory of patches" was more aligned with how I thought a VCS may represent a software project in time, but I also haven't gotten far with Pijul yet. It's just that somewhere between Git and Pijul, somewhere there is my desired to find a better VCS [than Git], and I suspect I am not the only one -- hence the point of the article, I guess.

That's just being pedantic for the sake of it.

Git is decades old. Of course, there are tons of contributions after the first 10 days. Everyone knows that.

He started it and built the first working version.

Even before git has the worktree feature, you could just clone the repo again (shallowly if it’s big).

$17M doesn't seem like enough for this. Perhaps for a prototype.