DEV Community

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/

Comment on git is not the end of history

tantaman

Matt Nov 27 '22

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.

GitHub logo facebook / sapling

A Scalable, User-Friendly Source Control System.

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 sl command 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...

View on GitHub

Top comments (44)

ingosteinke profile image

Ingo Steinke, web developer

Ingo Steinke is a Berlin-based senior web developer focusing on front-end web development to create and improve websites and make the web more accessible, sustainable, and user-friendly.

Location

Berlin, Germany
Pronouns

he/him
Work

Creative Web Developer
Joined

Sep 21, 2019

• Nov 24 '22

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?

jmfayard profile image

Jean-Michel 🕵🏻‍♂️ Fayard

One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.

Email

jmfayard@gmail.com
Location

Berlin, Germany
Education

ENSIMAG + Universität Karlsruhe (TH)
Pronouns

he / him
Work

Kotlin, Backend, Open Source maintainer, Technical Writing
Joined

Apr 19, 2017

• Nov 24 '22 • Edited on Nov 24 • Edited

Completely agree with your second paragraph.

misfeatures of git/GitHub/popular repositories to throw away meaningful commit messages that contributors might have taken a long time to describe properly.

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.

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?

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.

mattferrin profile image

Insight Lighthouse

Hi, I'm Matt Ferrin, specializing in TypeScript, Continuous Delivery, and Functional Programming. I also excel at imaginary conversations. Stay tuned for tech insights!

Location

Portland Oregon
Joined

Jun 3, 2019

• Nov 24 '22

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

jmfayard profile image

Jean-Michel 🕵🏻‍♂️ Fayard

One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.

Email

jmfayard@gmail.com
Location

Berlin, Germany
Education

ENSIMAG + Universität Karlsruhe (TH)
Pronouns

he / him
Work

Kotlin, Backend, Open Source maintainer, Technical Writing
Joined

Apr 19, 2017

• Nov 24 '22 • Edited on Nov 24 • Edited

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."

mattferrin profile image

Insight Lighthouse

Hi, I'm Matt Ferrin, specializing in TypeScript, Continuous Delivery, and Functional Programming. I also excel at imaginary conversations. Stay tuned for tech insights!

Location

Portland Oregon
Joined

Jun 3, 2019

• Nov 24 '22

I agree with this. For work, I put one link to the wiki location in the git readme and call it good.

mtrantalainen profile image

Mikko Rantalainen

Joined

Oct 4, 2019

• Nov 28 '22

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.

jmfayard profile image

Jean-Michel 🕵🏻‍♂️ Fayard

One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.

Email

jmfayard@gmail.com
Location

Berlin, Germany
Education

ENSIMAG + Universität Karlsruhe (TH)
Pronouns

he / him
Work

Kotlin, Backend, Open Source maintainer, Technical Writing
Joined

Apr 19, 2017

• Nov 28 '22 • Edited on Nov 28 • Edited

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?

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.

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.

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

GitHub logo jesseduffield / lazygit

simple terminal UI for git commands

CI Go Report Card GolangCI GoDoc GitHub Releases GitHub tag homebrew

A simple terminal UI for git commands, written in Go with the gocui library.

Gif

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...

View on GitHub

etienneburdet profile image

Etienne Burdet

Location

Paris, France
Education

École Normale Supérieur de Cachan / Le Wagon
Work

Fullstack dev at Egis
Joined

Dec 15, 2019

• Nov 24 '22

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.

jmfayard profile image

Jean-Michel 🕵🏻‍♂️ Fayard

One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.

Email

jmfayard@gmail.com
Location

Berlin, Germany
Education

ENSIMAG + Universität Karlsruhe (TH)
Pronouns

he / him
Work

Kotlin, Backend, Open Source maintainer, Technical Writing
Joined

Apr 19, 2017

• Nov 24 '22

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.

etienneburdet profile image

Etienne Burdet

Location

Paris, France
Education

École Normale Supérieur de Cachan / Le Wagon
Work

Fullstack dev at Egis
Joined

Dec 15, 2019

• Nov 24 '22

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.

panditapan profile image

Pandita

Reina Pepiada & Chilaquiles ❤️ .Net Developer. I like pandas.

Location

Mexico
Education

Computer Engineer
Work

Software Developer
Joined

Aug 22, 2018

• Nov 24 '22

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.

jmfayard profile image

Jean-Michel 🕵🏻‍♂️ Fayard

One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.

Email

jmfayard@gmail.com
Location

Berlin, Germany
Education

ENSIMAG + Universität Karlsruhe (TH)
Pronouns

he / him
Work

Kotlin, Backend, Open Source maintainer, Technical Writing
Joined

Apr 19, 2017

• Nov 24 '22

I hope hju actually exists at some point, it's very sad to see people frustrated with software, code, tools, etc.

This!

feynmanfan profile image

Chris B. Behrens

Joined

Nov 25, 2022

• Nov 25 '22

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.

jmfayard profile image

Jean-Michel 🕵🏻‍♂️ Fayard

One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.

Email

jmfayard@gmail.com
Location

Berlin, Germany
Education

ENSIMAG + Universität Karlsruhe (TH)
Pronouns

he / him
Work

Kotlin, Backend, Open Source maintainer, Technical Writing
Joined

Apr 19, 2017

• Nov 26 '22 • Edited on Nov 26 • Edited

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

dagnelies profile image

Arnaud Dagnelies

Location

Germany
Work

Developer
Joined

Sep 21, 2019

• Nov 25 '22

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.

jmfayard profile image

Jean-Michel 🕵🏻‍♂️ Fayard

One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.

Email

jmfayard@gmail.com
Location

Berlin, Germany
Education

ENSIMAG + Universität Karlsruhe (TH)
Pronouns

he / him
Work

Kotlin, Backend, Open Source maintainer, Technical Writing
Joined

Apr 19, 2017

• Nov 26 '22

Exactly. In fact Github perfectly fits the bill of "like git but simpler".

bitethecode profile image

Joonhyeok Ahn (Joon)

Craftsmanship. Slow life. I share what I learn about backend development, open source, and tech interviews.

Location

U.S
Work

Software engineer
Joined

Oct 30, 2022

• Nov 24 '22

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?

jmfayard profile image

Jean-Michel 🕵🏻‍♂️ Fayard

One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.

Email

jmfayard@gmail.com
Location

Berlin, Germany
Education

ENSIMAG + Universität Karlsruhe (TH)
Pronouns

he / him
Work

Kotlin, Backend, Open Source maintainer, Technical Writing
Joined

Apr 19, 2017

• Nov 24 '22 • Edited on Nov 24 • Edited

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/...

almostconverge profile image

Peter Ellis

Joined

Aug 1, 2018

• Jan 6 '23

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.

abentley profile image

Aaron Bentley

Joined

Nov 30, 2022

• Nov 30 '22

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

jmfayard profile image

Jean-Michel 🕵🏻‍♂️ Fayard

One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.

Email

jmfayard@gmail.com
Location

Berlin, Germany
Education

ENSIMAG + Universität Karlsruhe (TH)
Pronouns

he / him
Work

Kotlin, Backend, Open Source maintainer, Technical Writing
Joined

Apr 19, 2017

• Nov 30 '22

Just installed it, thanks!

tantaman profile image

Matt

Former trust, safety & privacy engineer @meta. Building platforms to scale knowledge work.

Joined

May 10, 2022

• Nov 26 '22

It already exists sapling-scm.com/

jmfayard profile image

Jean-Michel 🕵🏻‍♂️ Fayard

One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.

Email

jmfayard@gmail.com
Location

Berlin, Germany
Education

ENSIMAG + Universität Karlsruhe (TH)
Pronouns

he / him
Work

Kotlin, Backend, Open Source maintainer, Technical Writing
Joined

Apr 19, 2017

• Nov 26 '22 • Edited on Nov 26 • Edited

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.

tantaman profile image

Matt

Former trust, safety & privacy engineer @meta. Building platforms to scale knowledge work.

Joined

May 10, 2022

• Nov 27 '22

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.