Earlier quoted context omitted.
> As a trivial counter example Git does not currently have a way to store conflicts inside commits[1], which is one of our major features. Yes, I like how jj does it! Did a big `git rebase -i` yesterday and I felt stressed up, almost a bit angry, when there were some conflicts and I wasn't sure if I'd resolve all of them before it was time to leave, and work more later from a different laptop. But with jj, no stress:…
And you can deal with them in any order, bit by bit, or by adjusting things in earlier commits. I no longer fear rebase conflicts.
The creator of Jujutsu has joined ERSC
181–190 of 282 posts
Re: The creator of Jujutsu has joined ERSC
#182Earlier quoted context omitted.
> As a trivial counter example Git does not currently have a way to store conflicts inside commits[1], which is one of our major features. Yes, I like how jj does it! Did a big `git rebase -i` yesterday and I felt stressed up, almost a bit angry, when there were some conflicts and I wasn't sure if I'd resolve all of them before it was time to leave, and work more later from a different laptop. But with jj, no stress:…
And you can deal with them in any order, bit by bit, or by adjusting things in earlier commits. I no longer fear rebase conflicts.
Re: The creator of Jujutsu has joined ERSC
#183I like the idea of jujutsu, but I must not operate at a scale where its "killer features" would truly shine. Git hardly ever gets in my way, I have never had to do complex octopus merges or anything like that. It's usually: feature branch, implement, merge, and occasionally fix a merge conflict. JJ seems like it's more for people that like to have tons of active branches that they are constantly switching between whe…
A few advantages for me, even for the same 5 commands I use over and over: - undo - shuffling commits around with squash, split, and rebase is much better than git’s interactive rebase - make commits without having to come up with a branch name (I might make three versions of the same change in parallel to see how they compare) I see git is working on adding some of this under the history command. The revset language…
Can you explain this to me? I feel like Git is pretty easy there.
- select oldest commit to modify
- move the commits around with a mouse or the cursor
- close the editor to apply
Sure, the first step can go away (which is what they do with git history), but the rest seems pretty optimal to me.Alternatively I can add changes to older commits by recording them on top (--fixup) and tell git to auto apply them (--autosquash). I can also tell git to do the first thing automatically (git absorb, I believe it's inspired by jj).
Re: The creator of Jujutsu has joined ERSC
#184Re: The creator of Jujutsu has joined ERSC
#185I like the idea of jujutsu, but I must not operate at a scale where its "killer features" would truly shine. Git hardly ever gets in my way, I have never had to do complex octopus merges or anything like that. It's usually: feature branch, implement, merge, and occasionally fix a merge conflict. JJ seems like it's more for people that like to have tons of active branches that they are constantly switching between whe…
I was a skeptic until a few months ago. It’s my daily driver now. I’ve got sizable amount of people committing to the same repo, many are not skilled with git. So I deal with weird crazy “how did you ever get the repo into this state” issues not infrequently. JJ is just so low friction. The seamless and painless shuffling of commits, working up and down the commit chain without explicit rebasing, unchanging change-id…
Re: The creator of Jujutsu has joined ERSC
#186Earlier quoted context omitted.
1 more data point - it's very slow on my desktop which has relatively high performance as well. Using Brave if that matters.
We're about to push a change that should improve this a bit, thanks for the reports!
Good choice in my opinion, as I hadn't even noticed the animation existed until I looked for something that might make the scrolling slow.
Re: The creator of Jujutsu has joined ERSC
#187Earlier quoted context omitted.
Will this have any chance if Jujutsu/jj doesn't get more traction? The effort to learn a new VCS is less than for a programming language, but many developers have not learned git in depth, and Mercurial and others have not gained a lot of traction.
I'd argue that the reason a lot of developers have not learned git in depth is because it's actually kind of terrible from a UX standpoint (lots of inconsistent naming of things and somewhat leaky abstractions), and that Mercurial faced an uphill battle in large part because it lacked compatibility with what people were already using. I haven't used Mercurial, but from what I've heard quite a lot of how jj does thing…
Re: The creator of Jujutsu has joined ERSC
#188Jujutsu is a better smarter git. It's a great convergence of better UX, plus more expressive, plus easier to use. If you haven't tried jj yet, take it for a spin and see how you like it.
And if your muscle memory doesn't allow an immediate transition, give yourself 2 weeks. That's how long it took for me at least.
Invest in custom tooling and helper scripts.
Re: The creator of Jujutsu has joined ERSC
#189It will be good to see what jj will look like with more funded dev work, but I'm always a little worried about financial incentives mixing with the tools I use for the long term. I guess the saving grace is that I don't really need more upgrades to jj or jjui as it stands. I'm pretty much content with the features and so I could just save this copy of the repo for future reference.
As far as large assets goes, I have my own VCS-ish system which I just integrate with jj, but it would be nice to see a non-git backend handle large assets better as well.
Re: The creator of Jujutsu has joined ERSC
#190Jujutsu is a better smarter git. It's a great convergence of better UX, plus more expressive, plus easier to use. If you haven't tried jj yet, take it for a spin and see how you like it.
How does it compare to Mercurial? And why would it get more traction than Mercurial?
jj borrowed quite a few things from mercurial.
So, jj can be thought at least partially as a spiritual successor. Meta's Sapling is in a similar position. From this perspective, the key feature of both is transparent git repo and git remote support (hg can speak git as a foreign language, but it's limited)