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.
Care to point one concrete example?
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`.
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?
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?
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.
Your examples are laughable because most serious commands are way more complicated than that and again jj fixes that gracefully.
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?
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.
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?
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.
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?
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.
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.
> 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.
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.
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.
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 ;-))
jj is better.
If it's backed by git and doesn't break anyone else working on the repo, what's the problem?