Hacker News Reader

Comment by subpixel | Hacker News Reader

I was an English major and generally do not have the gift that makes programming come naturally. What skills I have, including passing Git proficiency, are the result of brute force learning, plus years of mistakes.

So I naturally assumed I could teach a team of non-engineers enough Git to enable them to interact with and contribute to text-only repositories as their job required.

I was quite wrong. Git flummoxes some people, and even the best visual tutorials (the ones that helped me immensely), leave some more confused than when they started.

YMMV but explaining simple Git concepts over and over in the face of incomprehension made me a bit of a dick too.

View on HN

Teach jj (jujutsu) instead.

The idiocy that is "staging" is the primary problem with Git. 99% of people do not need "staging" and yet Git inflicts it on everybody.

"Staging" (and "stash") makes Git modal, and that's a pain in the ass.

Having taught people both Mercurial and Git, I can tell you that teaching Git is simply a losing battle. Fortunately, jj operates just like Mercurial but can coexist in the Github ecosystem.

What is wrong with staging? I don't even consider staging until it is time to commit, at which point it is a little area to gather the exact changes you need.

Staging is an extra concept that adds complexity. Jujutsu shows you can achieve all the power of a staging area with strictly fewer concepts.

I don't know how others use it, but to me the staging area only lives for X seconds and acts as a last stop to simply select the exact changes and lines I want to actually commit. With a GUI, it becomes crystal clear as to what it is.

From what I can tell about JJ's split command, it seems like it does the same thing except you're working backwards to split out changes into another commit.

Both seems fine, I just don't see the complexity with the staging area (unless you're a beginner who's been told to only use the CLI at all costs).

These things add extra complexity throughout the ecosystem, not just for the end user. Most tools written on top of Git have to be aware of the staging area. Git's own developers, when adding new features to it, need to be aware of the staging area.

Jujutsu's authors have pointed out that a simpler model (here, and with first-class merge conflicts) helps them move much quicker. There are many weird and exceptional states with Git that just don't occur, so new features are more straightforward to add.

Mercurial is Git without at least 50% of its hassle. This was valid 15 years ago when I last worked with M, I suppose it didn't get worse since then but rather improved.

Shame Git won so vehemently, most software projects don't need that much power (and guns to shoot their own feet), but cargo-culting after Linus was too strong a lure I presume.

Jujutsu is by former Mercurial contributors, and is very heavily inspired by Mercurial.

Reply on news.ycombinator.com