Hacker News Reader

Comment by relistan | Hacker News Reader

I just want to say that we all finally are using mostly the same VCS and that is actually an undervalued, beautiful thing. An actual “standard” that is almost universal.

It used to be such a mess with all the VCS systems and having to know all of them to commit on various dependencies from different projects.

I know that jj can be backed by git. But already it doesn’t need to be. Between this and other projects, I don’t have to squint too hard to see a future that looks like the past. I hope I’m wrong.

View on HN

> I just want to say that we all finally are using mostly the same VCS and that is actually an undervalued, beautiful thing. An actual “standard” that is almost universal.

This bears repeating.

To further frame the importance of this, we've started seeing git being used as the deployment tool of some notable mainstream software projects such as nvm. This is only possible if a VCS becomes ubiquitous and a de-facto standard.

I think that's actually one of the nice things about JJ in comparison to many others (such as hg or Pijul): it uses Git essentially like a protocol or standard by which it communicates with other systems (and as a file-system standard, like using SQLite or something similar).

Essentially, it agrees that Git has become a de-facto standard as a file format and as a protocol, but that doesn't mean it can't have a very different approach to that file format and protocol.

It's similar to how HTTP can support a RESTful approach, or GRPC, or GraphQL or whatever else, and all these different systems can build on the same underlying technology.

> I think that's actually one of the nice things about JJ (...)

No one uses jj. You need to go way out of your way to install something like jj. It makes no sense to install jj so that they can install something else.

Not so with Git. Git is so popular that it comes pre-bundled with other critical software, and some OS distributions even install it by default.

Git is a problem-solver. JJ is a solution desperately looking for a problem, for which the right solution is already Git.

> Git is a problem-solver.

Git is also a problem-causer. The existence of sites like ohshitgit.com is testament to that. Git has wasted thousands of developer years with a terrible UI, overly-complex concepts, and lack of basic undo.

Some people have internalized, or worked around, git's flaws for so long, they can no longer even see them as such.

> The existence of sites like ohshitgit.com is testament to that.

It's a testament to worldwide adoption first and foremost. If `jj` had the same adoption, there would probably be similar sites about it. No tool is perfect, and all have their quirks.

I'm not sure that's a given. Lots of things have reached worldwide adoption and don't have the reputation that Git has. Bash, for example, is quirks and chaos galore, and I don't think even that has the same level of infamy that Git has. In fact, if we use the metric of "snarky XKCD cartoons about this topic", which is probably a good proxy for how popular a tool is vs how many serious problems it creates, Git is up there with Python packaging and regular expressions.

You're right that all tools have their quirks — jj is surely no exception. But it seems like bad engineering and a lack of curiosity to look at the quirks in a tool and not ask if we can do better. How much of a tool's difficulty represents the underlying complexity of the problem it's solving, and how much is just incidental complexity from the tool itself?

In this case, I think the core of Git (the underlying model of commits and refs and objects) does a really good job of being exactly what's necessary and no more, but the UI of Git (i.e. all the commands and surrounding paraphernalia) has a lot of incidental complexity. That is, there are simpler and cleaner ways to represent a lot of the stuff that's happening in Git. This, I think, is why a lot of people struggle with Git — not just because version control is hard (although it is), but because Git as a tool is additionally hard on top of that. And I think it's reasonable to look for better ways of doing version control that don't have as much incidental complexity.

> Git is up there with Python packaging and regular expressions.

Probably. And neither Python Packaging nor regular expressions will be replaced by anything in the next few decades, for the same reasons why `jj` is unlikly to replace git, for the same reason why rust won't replace C, and the same reason why, 20 years from now, people will still have jobs fixing Java and PHP code.

> But it seems like bad engineering and a lack of curiosity to look at the quirks in a tool and not ask if we can do better.

No one is demanding that we stop asking. But as engineers we cannot just consider "better", we also have to consider "practical". And in practical, pragmatic considerations, "technically better" simply isn't enough to displace an entrenched tool. That is a fact, whether people like that or not.

I like the ideas of jj. I cheer the development. Will I replace my git with jj in the forseeable future? No. Why? Because pragmatic reasons.

To replace an entranched tool that does its job and has wide adoption, a new thing needs to offer absolutely astonishing advantages that become "must-have" just by the merit of their existence. And even then, the ROI of these advantages have to offset all the technical and logistic pain of switching from one to the other.

> but the UI of Git (i.e. all the commands and surrounding paraphernalia) has a lot of incidental complexity.

There is no shortage of wrappers around git abstracting the nitty gritty to nearly any level of complexity desired. I use vim-fugitive for example. GUI abstractions as well as CLI tools and TUI wrappers exist.

> And in practical, pragmatic considerations, "technically better" simply isn't enough to displace an entrenched tool. That is a fact, whether people like that or not.

10% better isn't. 10x better is. Jujutsu is 10x better.

And this assumption is based on ... what exactly?

My long professional history working on source control.

I am not asking for opinions, I am asking for metrics.

10x is an arithmetic operation. Therefore, to make such an assumption, there has to be a quantity that operation can be applied to.

So, by what quantifieable metric is jj "10x better" than git?

I'm not sunshowers, but I think the point isn't the exact number or a way of measuring it. For example, the reason I prefer to write Rust over C++ is not that I have measured it to be 2.6X faster for me to work with. My interpretation of what sunshowers was saying was more like "'technically better' can be enough, depending on much better it is, and I think Jujutsu is a big enough improvement [for me] that it's worth it".

(Also not sunshowers)

For me, the important metric here is the intersection of two things: number of concepts, and power. I moved from svn to git relatively early in Git’s life; I started using GitHub in 2008. I’ve loved git for a long time.

jj has the ability to do everything git can, but has fewer primitives that are factored better. This means it is easier to use, while still retaining the ability to do anything.

I don’t know if that’s 10x, but it’s good enough for me that I’m never using git again.

I mean 10% and 10x metaphorically, the point being jj is much much much much better than Git. But I wouldn't be surprised if a dev can go from zero to being able to do complex history editing in jj, 10x faster than the same in Git.

> the point being jj is much much much much better than Git.

And I'll happily repeat: By what metric is it "better"? So far, I have heard your opinion, not metrics.

Both things are true at the same time.

Git is wildly popular, and a large part of that is its solid and fast technical underpinnings. Unlike its open source predecessors (svn/cvs), it excelled at distributed development.

At the same time, git also has a terrible CLI, combined with unnecessarily complexity like staging, stashes, rebase states, etc. This has been true from the beginning. Mercurial was built at the same time (also by a linux kernel dev!), and was generally considered to have a much better CLI and mental model. I think hg lost out despite that because it was slower than git, and didn't have Linus behind it.

> No one uses jj.

Plenty of people use jj. It just doesn't seem like that to you because it's client-side.

citation needed. also, define plenty. 1% of git total user base is plenty in nominal terms, I agree, but it's still 1%.

It's more than zero ie "no one", so GP is obviously wrong.

technically correct and completely missed the point.

It's hard to find that information because neither git nor jj report usage information to a central place. The best I've been able to find is number of Homebrew installs, which says ~1.2k 30-day install for jj and ~162k for git, so it's about 0.7% based on that number. Who knows how many of those installs (of either tool) are actually used as the person's daily driver.

I guess you don't use anything that's not preinstalled on your OS distribution then, lol

Jesus, what a hater Maybe one day you'll become self-aware

It's quite offensive to suggest that the people who built Jujutsu just did it for kicks. "[A] solution desperately looking for a problem"? Really? These are extremely competent engineers, world experts in the field.

It might behoove you to be a bit more curious about the deep intellectual lineage behind Jujutsu.

To generalise a bit, this is really an example of the power of having a common language. I find this is generally undervalued. Having a common language at all is more important than having a "perfect" language. People are too eager to disrupt the language. We instead need to embrace it for what it is, learn to work with it, and only change it in small ways.

If you're learning French you don't argue with the language and try to get French people to talk how you want them to talk, you suck it up and do what they do. As with all things it's a trade off: you get to converse with everyone in France, but, yeah, you will have to deal with saying "le parking" etc.

Git has lots of downsides, lots of power that forces you to work hard for things that should be easy.

jj is better.

If it's backed by git and doesn't break anyone else working on the repo, what's the problem?

A useful question is ‘how much better?’

For so many reasons, SVN to Git was a no-brainer but still constituted significant migration costs for existing teams and codebases: training, retooling, high-fidelity data transfer (you retained the commit history, right?).

For a tool with such wide adoption, motivating an ecosystem to move where there are many actors with different incentive structures, some of them will look and say ‘30% better isn’t even close to sufficient to spend time and $$$ on this. I would need ~10x better and/or a gain of altogether new capabilities impossible in previous tool to motivate that.’

It’s great that jj can be used independently without needing the whole ecosystem to move today, but once/if that part changes I’d expect it to be a long slog towards re-standardization if ever.

But jj likely already fully anticipated this given its compatibility with the Git wire protocol in the first place and I doubt it would ever give that up given the current landscape.

Given Jj has pluggbale backends, with two production ready ones and one test one, even if they did want to give it up, that would mean moving it to a third party, so like, yeah, not going away.

Agree with current state but I mean who knows how ecosystem might evolve… one vendor might ascend and embrace extend and extinguish on a separate backend. I think it unlikely, but it’s a possible path.

> jj is better

Primarily jj is different. And a lot of the "problems" it solves barely ever come up in git. And when they come up, its usually as "difficult" as "google the solution and enter the commands". And worst case scenario, someone has to manually copy paste some files around.

If this happened every day, I'd agree that we need a different system. But it doesn't.

In short, the situations where jjs advantages can really shine, and the advantages in these situations are simply not common enough / important enough to justify the headache of switching the world over to another VCS.

In an ideal world, "the better" solution wins.

In a pragmatic world of limited resources, "better" on its own is not enough. The differential between the new and the old solution has to be large enough to offset the cost of switching, and the more entrenched the existing solution is, the higher that cost will be.

But the world doesn't have to switch over to a new RCS. JJ works with git servers, so git can continue being the server, and people that don't understand git but do understand JJ can just run JJ.

> barely ever come up in git

Just because you don't run into that problem very often doesn't mean that other people, with different roles and workflows don't run into that problem more frequently.

> JJ works with git servers

For now. At some point, it may want to run features incompatible with git, and what happens then?

> nd people that don't understand git but do understand JJ can just run JJ.

And how many such people would you say are there? I am willing to bet that the vast majority of jj users know how to use git very well, and given the adoption of git, that is unlikely to change.

Secondly, git isn't just run by people, its run by scripts, pipelines, automated systems. git commands live in configurations, and elsewhere. Its a common language for how VCS works, not just a command line tool.

> Just because you don't run into that problem very often doesn't mean that other people, with different roles and workflows don't run into that problem more frequently.

It also doesn't mean that they do.

>> > JJ works with git servers

For now. At some point, it may want to run features incompatible with git, and what happens then?

Then we raise issue. But I don't have a problem with what someone else wants to run on their computer.

> But I don't have a problem with what someone else wants to run on their computer.

Neither do I. This discussion isn't about what someone else runs or doesn't run on their computers. By all means, run `jj`.

Or use `fossil`[1], which I maintain is technically superior to both `git` and `jj` (if you disagree, show me another VCS that also gives me a ticketing system, wiki, documentation system, forum and webui, all from a single executeable that allows me to set everything up with a few command line invocations ;-))

[1]: https://fossil-scm.org/home/doc/trunk/www/index.wiki

> Git has lots of downsides, lots of power that forces you to work hard for things that should be easy.

Care to point one concrete example?

I'm working on a change when a review comment comes in. I want the review ping-pong to move fast so I want to pause my work on the current branch and address the review comment.

I can either stash my changes, which requires keeping a mental model of the stash queue (what if the review comments took a while and I started working on something else?) or a "wip commit", which you need to know, and you need to know how to reset and force push if you accidentally push it.

With jj, you run `jj edit`.

> I can either stash my changes, which requires keeping a mental model of the stash queue (what if the review comments took a while and I started working on something else?) or a "wip commit", which you need to know, and you need to know how to reset and force push if you accidentally push it.

You do:

git commit -m "wip"

Then, if you wish to undo the commit then:

git reset HEAD

If instead you want to update your commit with additional changes:

git commit --amend

Seriously, why are you guys advocating for replacing a tool when the problems you're actually experiencing are due to your inabilility to learn the basics of it? I mean, is jj edit any better than git commit --amend ? Does git commit --amend require more cognitive load to understand?

The git command line is an awful thing that should have been fixed a long time ago. jj fixes it while staying compatible.

Your examples are laughable because most serious commands are way more complicated than that and again jj fixes that gracefully.

> The git command line is an awful thing that should have been fixed a long time ago.

Again, please point out your best example that you believe proves your point.

All I see so far is shit-talking Git with abstract unsubstantiated complains to then hand-wave an alternative as the savior.

Point exactly where Git fails and what value is brought to the picture by any other alternative. Clearly Git's backend is not a issue by the way jj reuses it. So what exactly are these problems that are worth solving?

Lol being angry that other people don't think git is easy to learn and that it's not perfect isn't going to convince them of anything other than you're an angry person.

https://ohshitgit.com/ has plenty of exmaples that you're free to disregard as being shit-talking. Meanwhile, the rest of us can admit that git has some rough edges, like how git checkout does a couple of different things, depending on the flags you pass it. That's not user friendly.

Thank you for proving my point.

What you really want to do is

git commit -anm "wip"

The -a is important because maybe you haven't staged the changes yet. The -n is important because otherwise your pre-commit hooks will run, and potentially modify your commit.

Also, what happens if some of the files were partially staged?

> What you really want to do is

No. I only need to run hit commit. The rest is just silly attempts to nitpick your way to faking complexity where there is none. You don't need to pass --all because you should know and tell what changes go into the commit. You don't need or care to skip precommit hooks, because either you don't have any or you have them and you want to run them. That's it.

Also, even your attempt to make a mountain out of a molehill ends up with a easier, smaller command line entry.

I have no horse in this race but it seems to me that you're not understanding their point. JJ has a different workflow that doesn't have a concept of a staging area, for one. The fact that you don't need to make a WIP commit may not be a game-changer for you, but it demonstrates that the abstractions it provides more accurately represent the "editing a previous commit" workflow. If that's not useful to you, fine. But I think it's valuable to have tools that 1) integrate into existing (git-based) systems with low friction and 2) provide abstractions more suitable for the work I tend to do on a daily basis.

The OP knows how to do this but finds it unintuitive and inconvenient. You didn’t read their comment correctly and became verbally abusive.

> The OP knows how to do this but finds it unintuitive and inconvenient.

That's not a credible explanation. Amending a commit is somehow unintuitive and inconvenient but editing a commit is suddenly so much clearer and intuitive?

There's also another problem: The git workflow doesn't jell with the natural flow of code review.

What should that flow look like?

1. You send out a change for review. 2. You get review comments. 3. You fix the comments. 4. Repeat from #2 as many times as necessary. 5. You merge the change.

In git, how do you address review comments? You can either amend, in which case, at least on Github, you lose history while in review; or you add another commit, which essentially forces you to squash when you merge, which results in large commits.

How do you do stacked changes? How do you continue working on your feature while waiting for a change to be reviewed, and rebase the comments quickly?

With jj, it's jj edit and jj next.

> How do you do stacked changes? How do you continue working on your feature while waiting for a change to be reviewed, and rebase the comments quickly?

What? Are you actually asking this question? I mean, what answer do you need other than a basic intro to PR tutorial from the likes of GitHub or GitLab?

But to answer your question, you continue working on your feature exactly like you've been working so far. You do not need to amend or squash. You can instead do the right thing and address PR feedback by pushing individual commits. How the PR branch is merged is a separate concern, and you are free to squash or rebase or whatever you'd like, because none of this is a Git issue.

Why do you think this is an issue with Git?

> or you add another commit, which essentially forces you to squash when you merge, which results in large commits.

Please no. Just do a normal merge instead of destroying history. Having those as separate commits is extremely useful for those of us who actually have had to dig into the history to track down why something is the way it is.

Mostly everyone using the same standard is amazing. Power tools batteries are the glaring failure. Kubernetes gets a lot of shit for being complicated, which it should, because it is, but I'm glad that enough people use it to manage their fleet of computers that I don't have to learn too many special cases for managing fleets of computers.

XKCD 927.

git is good (good enough even) but not perfect. I’d love to see pijul receive funding for a small team for a couple years but we’ve got what we’ve got.

jj’s killer feature is git compatibility, obviously. For now it’s table stakes so we can pretend only git exists.

Reply on news.ycombinator.com