What comes after Git

Linus Torvalds developed it after the spat with Bitkeeper, which was the main public proprietary dvcs.

In a short time it became the most popular one. Which means all these people must be wrong otherwise.

OpenBSD can use CVS cause they have a small, relatively static team.

So here's what I think of these points, as well as how my VCS will address them.

1. Atomicity across projects: this is a good point, a necessary one. When I asked people why Git submodules are so bad [1], that was the biggest point. My VCS will have this, even though I haven't quite figured out how to do it yet. I'm almost there.

2. Native package management: my VCS will have this, sort of. The thing is that I hate CMake, so I'm building a build system, and while doing the design of it, I realized people are doing build systems and package managers wrong. So I'm working on that too. Needless to say, my package manager/build system will be well-integrated into my VCS. (My package manager will also have another shtick: you can set security policies for individual packages, which means that situations like where npm packages become malware should not cause damage.)

3. Semantic diff: I have figured this one out. It will exist. It will be language-specific, but all that it needs is a lexer for the language and a dumb understanding of the structure. This same system will also be used for diffing and merging binary files, such as Blender files, PNG's, executables, PDF's, files for Microsoft Office, files for LibreOffice, etc.

4. Merge queue data structure: my VCS will have something that will serve this purpose and could probably implement a high-level interface to it, like Git has porcelain over low-level operations. However, what I have actually designed is so powerful, it will also be capable of real-time collaboration and of implementing full undo/redo.

5. Fan-out pull requests: this is currently not in my plans (I think better package management would handle most or all of this), but it would be trivial to implement if people want it.

6. Terrible UX of Git: I'm going to spend the time on this upfront. In fact, I want to do user testing with non-programmers until they find it easy. I will take inspiration from Mercurial for sure, but the user testing results will be the most important.

7. Large file storage: my VCS would be completely inductive at binary files if I didn't have a plan for this. I do have a plan, and I will be testing on large files, including up to multiple terabytes, from the start.

8. Project management hooks, but not features: there will be built-in features for things that should always be there (issues is one, I believe), but there will also be a way to set up your own. They won't be hooks, per se, but it will be possible to create the project management "flavor of the month."

Comments on these are welcome.

[1]: https://news.ycombinator.com/item?id=31792303

Then the 120k+ files in node_modules is in there forever, far outliving that team member's career as a software developer.

If the user has not yet synced those changes to a central repository, they can still delete their copy, re-clone, and re-do their checkin to be "less encompassing." Once they push, however, all of their coworkers will hate them. The fact that pushing would take noticeably longer than it should for that case would be the first hint that tapping ctrl-c would be in order (that is, cancelling the sync with the upstream repo).

> ... it's there in the history forever?

Until/unless it's "shunned" (which would take extraordinarily long to do for 120k files, as shunning requires the artifact IDs of every file to be shunned, and if a single one of those hashes is the same as a file which should not be shunned (e.g. all empty files have the same hash) then tough luck).

It seems likely, however, that new developer's colleagues would have long since added `node_modules/*` to the repository's `ignore-glob` setting so that the new colleague wouldn't accidentally add that.

Sidebar: in my 14+ years of being active in the fossil community, nobody's yet posted saying they've accidentally checked in a node_modules directory and asked for advice on how to deal with it. Presumably node folks primarily exist in Enterprise environments, and Enterprise environments all use git because that's where the tooling is.

Though even knowing, Mercurial is still a better experience, but not by enough.