I hereby am foolish enough to predict that in 5 years for now, we will see a new tool for version control, let's call it hju, that will attract millions of developers on a promise that could be "hju is like git, but simpler".
Specifically:
- hju concepts will be a lot like git, you will have commits, branches, sha1, clones, ...
- hju will have great interoperability with git. Importing your GitHub repository into hju will be one click. Transforming you hju repository in a git repo will also be simple.
- hju will struggle to find a business model that supports a team strong enough to build a tool concurrent to git. Probably the main hurdle right here.
- hju will not try to have feature parity with git. git can support all the complex workflows you have not imagined yet. The more complex workflow will stay with git. Especially projects like the Linux Kernel, bazaar projects that are completely decentralized, will see no point in migrating to hju.
- hju will instead work hard to make the life simpler for the vast majority of projects where a small number of developers work together, know each other, trust each other.
- git will probably have more users than hju for a long while. But there are enough developers that having for example 20% of the market is completely sustainable.
- hju on the other hand will be focused on the most common usages of version control. It will be designed for usability. It will be significantly harder to fuck up things with hju than with git.
- hju will lower the cognitive load. When submitting a pulll request, you will feel that you are more focused on the task at hand rather than on what your control version tool expects from you.
- hju will discourage practices like rewriting history that makes it so enjoyable to shoot yourself in the foot. It will push the idea that it's OK if the hju history inside a PR doesn't look like what should have happened, but instead like what actually happened. It will encourage people to have small PRs focused on one thing and that can be squashed (squashing will be the default).
- hju will have a vastly better learning curve than git. At some points bootcamps and university courses will teach hju rather than git because the ratio of concepts learned over time spent is so much better. There will be great tutorials on the internet on how to learn git if you already know hju.
- hju will just work on Windows and Android
Best case scenario: Microsoft has already a secret internal project similar to hju and will make sure GitHub can make it an implementation detail of whether you use git or hju.
Dear readers, what's the best and the lamest part in my prediction?
Since you too can predict the future, how do you see the future of version control?
Update: Two astute readers told me that hju might already exist. Facebook recently open sourced the version control tool that it has been using for 10 years:
Have a look at https://sapling-scm.com/
Yeah. I used it for 8 years while there and just started again now that it’s open source.
It makes it trivial to maintain a linear history and takes all the fear out of rebasing. Amending commits that have had changes requested during code review is painless (via absorb) as an example.
most operations are simple and easy to remember rather than all the git craziness of heads, caches, soft resets, hard resets, reflogs, etc.
Sapling SCM
Sapling SCM is a cross-platform, highly scalable, Git-compatible source control system.
It aims to provide both user-friendly and powerful interfaces for users, as well as extreme scalability to deal with repositories containing many millions of files and many millions of commits.
Using Sapling
To start using Sapling, see the Getting Started page for how to clone your existing Git repositories. Checkout the Overview for a peek at the various features. Coming from Git? Checkout the Git Cheat Sheet.
Sapling also comes with an Interactive Smartlog (ISL) web UI for seeing and interacting with your repository, as well as a VS Code integrated Interactive Smartlog.
The Sapling Ecosystem
Sapling SCM is comprised of three main components:
- The Sapling client: The client-side
slcommand line and web interface for users to interact with Sapling SCM. - Mononoke: A highly scalable distributed source control server. Not yet supported publicly, OSS is…
Top comments (44)
squashing should never be the default in my opinion. we can squash, edit, pick and edit locally, but to me it is one of the misfeatures of git/GitHub/popular repositories to throw away meaningful commit messages that contributors might have taken a long time to describe properly.
Another misfeature of current version control is rather a shortcoming of the default diff algorithms, producing too many "changes" and "conflicts" like when two different additions have been made to the same file, or when indentation changed so that editing two lines produces pseudo-change noise of any nested lines. This might also be the main reason making it so painful and dangerous to rebase in complex projects.
Good idea for hju: forcing developers to make small pull requests (following the principle of trunk based development) but how exactly would we force fellow developers to do so?
Completely agree with your second paragraph.
That's just my opinion but I think long descriptions should go in the issue trackers, pull requests discussion, company wikis. Easier to update. Easier find after the fact. But not in the git descriptions. For documentation, being immutable is an anti-feature.
Git didn't have an issue tracker, because the Linux developers already did those things by email, so for them the long detailed descriptions in the git messages made total sense.
Not forcing but nudging.
Nudging by making squashing the default.
You can only squash pull requests that are focused on one thing.
That's a useful friction here.
I think you could have a websocket write conflicts into a separate adjacent file dynamically. Then it’s a little like Google docs if everybody detects and aligns changes immediately.
If 2 people can’t immediately align their local changes, it surfaces a disagreement or lack of understanding. It might be a disagreement about something petty though. Everything comes with a trade off.
@jmfayard @ingosteinke
Your comment reminded me that git (and hju) is by default the wrong choice for documentation.
We overuse it because we know git, but frankly pause and reflect the next time you want to do that.
Basically Wikipedia is the proven method for collaborating on documentation.
Git is the newer kid that does it worse and add tons of overhead.
You can have counter examples like a static blog where you are the only one and commit on main and need to use a CI. Ok then that's fine.
But in general documentation is a completely different use case than software.
Think about those 420 awesome-something github repositories that could have been one wiki instead.
You don't need a global history of commits that span multiple files.
You need multiple histories, one per file, that are mostly independant
(just make sure to support renaming).
Most importantly, for documentation you want to remove the gatekeepers that nitpick your pr.
The inventor of the wiki correctly stated that it was inefficient because "The best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer."
I agree with this. For work, I put one link to the wiki location in the git readme and call it good.
I fully agree. I have found that all supporters of squash commits either create so low quality patches that keeping commits separate just adds noise or they want to use some tools that cannot handle anything more complex but a single commit (e.g. Gerrit?).
I find that never using squash but rebasing feature branches is much much better in long run. Yes, I might combine some patches in the process to create easier to understand history but never squash everything without thinking.
And i always find it funny when software developers complain that the concepts used in Git are too hard to learn. How on earth do you think you can write correct programs if you cannot even wrap your mind around as simple as Git?
Some old git commands do have poorly named flags and some commands like checkout and reset have way too many modes, but those cannot be fixed without breaking backwards compatibility.
Maybe we should have easy-git (eg?) that is just an alternative command line interface to git, where the intent is easy to use instead of backwards compatibility. Of course, that would prevent scripting those commands because your scripts would fail when its interface is "improved" in the future.
That's pretty simple really, i'm more likely to write correct programs if I have less cognitive load to spend on my version control tool. And to other things unrelated to the task at hand.
What happens is that some people have spent huge amount of times polishing their git skills, and written thousands of commits in git, doing hundreds of rebases, practiced the best practices, ... so they are like long-time users of emacs. For them everything make sense, feels productive and there is no point in using something else.
Personally I'm more interested in the beginner's mind than in the expert's mind. With sufficient training, everything seems OK.
Agree, you can't touch /usr/bin/git itself because it's like the low-level library that everone relies on.
I'm using lazygit when I'm in the terminal, does the job really well
simple terminal UI for git commands
A simple terminal UI for git commands, written in Go with the gocui library.
Sponsors
Maintenance of this project is made possible by all the contributors and sponsors. If you'd like to sponsor this project and have your avatar or company logo appear below click here.💙
Elevator Pitch
Rant time: You've heard it before, git is powerful, but what good is that power when everything is so damn hard to do? Interactive rebasing requires you to edit a goddamn TODO file in your editor? Are you kidding me? To stage part of a file you need to use a command line program to step through each hunk and if a hunk can't be split down any further but contains code you don't want to stage, you have to edit an arcane patch file by hand? Are you KIDDING me?! Sometimes you get asked to stash…
Funny, I never though of challenging git… and yet now you say it.
Conceptually, I really like the idea of git with stricter flow—a bit like React enforces one way data flow over bindings. Like default protected main branch that only merge with PR, no cherry pick between branches, no "cross-path branches" etc. Start your feature/bugfix, work there and then push to main and that's it. Today we have so many ways to deploy branches that it could make sense.
A last opinion, that might not be the most popular: I think a "branch/feature/bug etc." should always rebase itself vs. main, not merge. It would be easier to understand. Your modifitations are always after the "main" branch until merged. And hju should make that easy 😛 How? I have no idea.
Thanks a lot.
is your last paragraph something different than nudging people to squash their pull requests? That's already what we do on GitHub.
Well, when squash-merging your PR, you have resolved conflicts in the first place. For new and old dev alike it's often it's often done by merging main at the end. Along the way I learned the many benefits of benefit of rebasing often. But right now it implies force pushing, continue/skipping etc. While merging leads to situations where all of a sudden you have tens of other people commit in the middle of yours.
I think a system where your branch always live "at the tip of main" (conceptually, wether it is really a background rebase, or just a final merge, I have no idea!) rather than where you started, would really decrease the final merge cognitive load. Squashing helps indeed, but I think it's not the whole story.
I respectfully disagree. There is a vast scrapyard of interfaces to make Git easier to work with - the truth is that the easy things in Git are easy, and the hard things are hard because they represent a sophisticated set of decisions that cannot be simplified and remain meaningful.
Git is as good as it is going to get as long as we're version controlling the broad class of ANY text file. To make a big step forward, you either have to restrict to a smaller class of problems or the broad class of problems has to collapse into that smaller set on its own, which will eventually happen.
I don't disagree but I also note that there is a resistance against using the tools that make git easier to work with. People will insist you must learn the CLI. I respectfully disagree and think like Arnaud Dagnelies in the comments that git was successful because Github made it much simpler
You know, I wouldn't mind a more "simpler" git. In my current project people who have no idea about software development are forced to use git because the projects are in .Net (and made by mech engineers!).
They constantly say they hate the .Net projects because it's hard and I totally get it! When you're busy trying to get an industrial machine running, seeing a null reference exception has to be the equivalent of a middle finger. Then comes Git, with it's weird terms like branches, head, merge and rebase. If I was in their position I would be like I DON'T GET IT AND MY BOSS WANTS THE MACHINE TO RUN ASAAAAP ugly crying
So, a much more simple or simplified Git would probably help them a lot in this case (I don't recommend replicating this case though).
I hope hju actually exists at some point, it's very sad to see people frustrated with software, code, tools, etc.
This!
I think GitHub alone is the reason of git's success. And Linus too when it started. This combo made a fast growing community that had a huge networking effect. Otherwise, I think the now long forgotten Mercurial would have won the race, it was basically a similar tool, just easier.
Exactly. In fact Github perfectly fits the bill of "like git but simpler".
Interesting prediction. I don’t like to shift tools for insignificant value a new tool bring. Git especially handled most of problems vcs had previously and became universal. Unlike Git, I’m ready to jump if someone make a better tool to replace Jira.
What things do you think Git sucks?
git doesn't suck. It's the best possible version control system in the context where it was produced, i.e. the Linux Kernel, i.e. an ultra large bazaar style project with hundreds of developers gifted at getting the low level details right.
It was not however designed for the kind of projects I work on, more Cathedral style, a few people who know and trust each other, where learnability, usability, and just not getting in the way are important factors.
The SQLite people have a concurrent to git called fossil. You don't have to switch. But I found their description of why they started and maintain the project incredibly interesting and stole many ideas from it
fossil-scm.org/home/doc/trunk/www/...
My dream is an SCM that is language-aware. In fact the SCM doesn't even have to know about this, only the diff engine.
So when for example dev A reorders some functions in a file and dev B modifies a line in one of the functions, the diff/merge process can work out automatically what happened instead of throwing it back as a conflict.
It's 2023, there are ASTs in my fridge display and developers are still diffing everything line by line, how did we even end up here.
I've been writing a git wrapper called oaf that has many of the properties you're discussing. As a past Bazaar developer, I'm trying to bring the UI advantages bzr had to the Git format.
github.com/abentley/oaf
Just installed it, thanks!
It already exists sapling-scm.com/
I wasn't aware of Sapling before you and another commenter mentionned it.
Do you have experience with it?
I wonder if it's taylored to Facebook needs or to the avergae IT projet.
Edit: Facebook use it internally since 10 years. Super interesting. Will follow what happens with it.
Yeah. I used it for 8 years while there and just started again now that it’s open source.
It makes it trivial to maintain a linear history and takes all the fear out of rebasing. Amending commits that have had changes requested during code review is painless (via absorb) as an example.
most operations are simple and easy to remember rather than all the git craziness of heads, caches, soft resets, hard resets, reflogs, etc.
Interesting Prediction!