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.)
- EdenFS: A…
Oldest comments (44)
Interesting Prediction!
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/...
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…
only after reading again more carefully, the parody aspect comes out more clearly. So if this is supposed to be like yarn vs. npm, I predict: hju will gain a lot of user adoption in a certain scene only, all the improvements will be ported back to git, but people will still argue about which one is better even after both will be hardly discernable.
How can something "only work on windows and Android" these days? And which Android version? Probably we will need Kotlin and gradle runtimes matching peer dependency versions exactly, so hju will soon be much worse than git in many respects, but people will still defend its benefits and engage in hate and flame wars on twitter about it!
It's not a parody, apart from the inevitable joke that you can't predict the future.
Unless you are working at Microsoft on a git replacement that will be made available as an option on GitHub.
Which I'm not :)
I'm on the JVM and our two build systems are Maven and Gradle.
Put 10 programmers in a room and you will never have an agreement on which one is the best.
But there are meaningfully different.
That's the ideal case where we have two similar tools but that address the needs of quite different contextes.
I think you read too quickly here. I was saying that git was designed for posix systems and is a bit of an alien on Windows and Android.
I don't think that there are many Android apps using git? I tried to, via the NDK and libgit, it was really not nice.
I did not really do any serious native app development so far, so I can't tell. As a web developer, I would always go for a web app / PWA if possible.
Either way you can't rely on the git executable to be installed on your smartphone.
Asking for the user to install the git executable
well I have tried to do git myself with termux multiple times and failed every time.
That's why Android apps propose you to sync with Dropbox or Google Drive but almost never with git.
So you mean for versioning user content? Good idea, never even came up with that. I used to have git and a terminal on my smartphone, but I never really used it for development purpose as the screen is too small for actual development, but a git client might be useful, but probably something more lightweight than git actually.
My use case is that I use obsidian.md/ as a markdown-based offline wiki.
Obsidian is basically VS code for words - instead of code.
There is an obsidian-git plugin that is very handy to sync things obsidian.md/plugins?id=obsidian-git
Obsidian works on Android, and obsidian-git would if I managed to install git.
But so far I didn't :)
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.
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!
intresting
Am I the only one not seeing the difficulty of git? I don't remember having struggled to learn it, and I love the versatility of the tool.
I agree a stricter vcs may help in professional settings (though you already have that through branch protection and the like, why also having it in git?) , but in general I love the power to do anything (squash, merge, amend, edit, undo, etc).
Like with every software, you can evaluate that by doing usability testing in the wild. Take someone who has done less than 1.000 commits, give them tasks to do without telling them how and watch how they struggle with git.
That should be eye opening.
Another way to do the same thing is to look at stakoverflow answers for git and be amazed how super simple tasks with git get millions of views because
git --helpandman gitdidn't give people the obvious solution they were looking forstackoverflow.com/questions/tagged...
Here for example a huge amount of traffic for... finding out what's the current branch?
Same on DEV.to (and everywhere on the internet), git topics get you an amazing amount of traffic
dev.to/t/git/top/infinity
As a content creator, I have to admit that git is the best topic ever. There is such a huge need to translate git speak to human speak
I am not sure you can use those statistics as a good indactor. Git is used by pretty much everyone in the dev community, and is around for a long time. This could easily explain the scores on stackoverflow.
Dev.to is mostly for beginners and web devs. The analysis in my recent article dev.to/derlin/devto-is-for-webdevs... would also perfectly explain why git is popular on this platform.
Not saying you are wrong, just that those two arguments are not enough to convince me.
I would say the popularity of stackoverflow questions is more ore less
popularity / usability. Git's popularity is super high which is obviously explains half the explanation.I'm also convinced that if git was more usable people would need to google & stackoverflow things much less often. For example I use the
herokuCLI which also does pretty complex things, but I don't often need to google and stackoverflow its syntax, it's pretty straightforward.Okay that's a good point :)
But in this case, I would be for improving the doc and cli of git rather than replacing this a simpler, more limited tool. I would also stress that git has an amazing online doc, which users often bypass completely.
That being said, I loved the thought experiment, and agree there is room for improvement. Let's see what happens in the future ;)
I'm all for using better terminal clients like lazygit github.com/jesseduffield/lazygit
You cannot change anything in
gititself, becausegitis not only a git client, it is also a library used by many many scripts and apps. If you remove a command-line flag that almost no-one uses, there is an app that will break somewhere.git's documentation isn't amazing, it has a chicken & egg problem. To know which part of the documentation you need to read, for example
man git-reflog, you need to know most of the answer already ("that's the kind of issue I can solve with git-reflog"). That's why git's documentation is the whole internet instead.Check out a new source control from Facebook called Sapling:
github.com/facebook/sapling
Holy shit, I had no idea
And it does look a bit like what I had in mind
sapling-scm.com/docs/introduction/...
Also being made by Facebook, this solves the hurdle of struggling to find a business model.
Do you even lose the commit messages if you can just reopen the merged PR after reverting a squashed commit?
I'm very pro-squash as it keeps the main trunk clean and avoids situations where people revert only portions of their PR, instead we revert the entire squash and they reopen their feature development branch.
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".
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
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.
hju sounds a lot like mercurial 2: electric boogaloo
I'm not entirely sure we need a new VCS to achieve most of this. A lot of it can be done through guidelines and a good UI (which could be either a GUI or a CLI) on top of git. For me git is pretty easy and simple : I use it through Jetbrain's IDE 90% of the time and I chose to completely ignore rebasing and encourage my team not to use it : our commit history doesn't look clean and so what ? At least it shows what actually happened.
For the same reason I'm divided regarding S
Squashing on PRs : On the one hand it does make it things cleaner and prevent commit messages that are hard to understand out of context, but on the other hand you lose the justification for a specific change. Sometimes I don't care that you changed a variable name 2 years ago to make it more consistent, I just want to know what feature that part of the code relates to... And sometimes I do want to know why that variable name was changed.
I think what I'd really like is a way to keep all the commit, but bundle them together with a message that explains the whole feature. I mean that's what PRs are for, but as far as I know you can't really see the PR from git once it's been merged since they're handled by your repository and not in git itself... So I guess that's the thing I'd like to see added in a got successor : a way to keep both individual commits and merged PRs.
JetBrains git integration is amazing, I have an article planned on this.
Squashing on GitHub works exactly like you say. If you look at the main branch, it's only one commit, but if you need the details, you click on the link to the PR and you can see what happened step by step.
I agree, the issue is that there is a strong culture in the git community that goes against that, that discourage people to use git clients, that pushes "best practices" that reflect what they think is the one true way to use git, ...