Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jujutsu (jj), a Git compatible VCS

tonyfinn.com

Post reply on HN
Print view View original

11–20 of 117 posts

Re: Jujutsu (jj), a Git compatible VCS

#11

Post by emacsen »

cupofjoakim wrote: post #2

I'm still unsure of why I'd want to move to jj from git. My ideal git workflow is pretty simple: 1. `git switch -C new-branch` 2. Make changes, time passes 3. `git add .` 4. `git commit -m "Description of changes made"` 5. `git fetch && git rebase origin/main` 6. `git push` 7. Make pr to main If main is out of date I rebase again to update. This to me feels pretty light weight and is not a hinderence in any way on my…

There are three answers to this.

1. If it works for you, no need to stop

I remember plenty of people who used SVN saying why did they need to use git. In fact, I remember companies complaining about distributed version control generally, saying they preferred centralized version control.

If it works for you, you can keep using it. No one will stop you, but you may find that just as SVN users have largely shrunk down, maybe the same will happen with git.

2. jj today

I use jj today and the biggest advantages for me are not needing to worry as much about the order of operations.

I write some code and then I come across a bug. I can pull out the bug and fix it while still working on my existing code. I don't have to go back in time to fix it.

I also appreciate not needing to stop just because of a conflict. This is something I miss from SVN, which was similar-ish in that conflicts didn't need to be addressed immediately, only jj's implementation is better.

Generally I find the jj workflow to be something that takes a few days of adjustment, then it just makes more sense.

3. The way things will be

jj is still relatively early. The commands to interact with git aren't all very intuitive or easy to use. I had to make some aliases to make this easier. More importantly, there's no jj backend yet. Once that happens and it's adopted by forgjo or another forge (Gitlab, Github), I think we'll see a big shift towards it.

I think git is going to be around a long time, but the day to day use of jj is so much nicer than git that I hope it will gain fast adoption.

Re: Jujutsu (jj), a Git compatible VCS

#12

Post by keybored »

ocular-rockular wrote: post #4
lawn wrote: post #3

Earlier quoted context omitted.

One advantage is that jujutsu tracks merge conflicts so you don't end up in a situation where you'll have to resolve the same conflict more than once, which may sometimes happen with git.

But why build a whole VCS around that one use case? I looked through the docs and honestly it looks like it complicates life instead of making it easier. edit: everyone is so focused on the "single use case" part and not the fact that it looks more complicated and verbose than regular git. Unless everyone using it is some git god that runs into edge cases left and right... maybe my workflow is just not that complicat…

It’s not necessarily the only use case.

But as I’ve read (according to Martin) doing it this way simplifies the implementation a lot. You track everything directly in the DB. In turn you don’t have to care about all sorts of states like being in conflicted git-am state, conflicted git-merge, etc.—these states cannot happen, it’s all in the DB (not some dirty working tree state where some flags or files somewhere in `.git` or `.jj` tell you “there are some conflict markers thereabouts, enjoy”).

And that frames it in terms of being easier for the people implementing jj. But I think it will also benefit us users by making it easier for them to create streamlined tools.

git-rebase(1) and all that is great and all. But definitely messy. And we only recently got `--update-refs` to update dependent branches, which is kind of late considering how important branches are in Git.

Re: Jujutsu (jj), a Git compatible VCS

#13

Post by zug_zug »

ocular-rockular wrote: post #4
lawn wrote: post #3

Earlier quoted context omitted.

One advantage is that jujutsu tracks merge conflicts so you don't end up in a situation where you'll have to resolve the same conflict more than once, which may sometimes happen with git.

But why build a whole VCS around that one use case? I looked through the docs and honestly it looks like it complicates life instead of making it easier. edit: everyone is so focused on the "single use case" part and not the fact that it looks more complicated and verbose than regular git. Unless everyone using it is some git god that runs into edge cases left and right... maybe my workflow is just not that complicat…

Moreover, even if it was say 15% better than git (and I doubt it is), the overhead of moving a whole industry across VCs is billions of dollars of loss.

Every single engineer has to start over in their mastery experience by learning all the new quirks and issues, and all the tools, libraries, pipelines need to be rewritten.

IMO better to support the dominant tooling than invest in fracturing one of the few areas where engineers can agree on something for once (to everyone's benefit).

Re: Jujutsu (jj), a Git compatible VCS

#14

Post by fulafel »

Is there a sales pitch for git users who are of the history preservation school of thought, does the changeset id stability help tracking what happened in the automatic merge heuristicss applied during rebases?

Re: Jujutsu (jj), a Git compatible VCS

#15

Post by MarceColl »

cupofjoakim wrote: post #2

I'm still unsure of why I'd want to move to jj from git. My ideal git workflow is pretty simple: 1. `git switch -C new-branch` 2. Make changes, time passes 3. `git add .` 4. `git commit -m "Description of changes made"` 5. `git fetch && git rebase origin/main` 6. `git push` 7. Make pr to main If main is out of date I rebase again to update. This to me feels pretty light weight and is not a hinderence in any way on my…

And what are the steps when you work on 3 things at the same time (you are working on PR #2 + fixing issues in PR#1 + a hotfix needs to be deployed for an issue)? Or when you need to continue fixing things on the PR?

On the absolute happy path what you do above is the same I do, where jj shines is when you het out of the happy path.

Re: Jujutsu (jj), a Git compatible VCS

#17

Post by lawn »

ocular-rockular wrote: post #4
lawn wrote: post #3

Earlier quoted context omitted.

One advantage is that jujutsu tracks merge conflicts so you don't end up in a situation where you'll have to resolve the same conflict more than once, which may sometimes happen with git.

But why build a whole VCS around that one use case? I looked through the docs and honestly it looks like it complicates life instead of making it easier. edit: everyone is so focused on the "single use case" part and not the fact that it looks more complicated and verbose than regular git. Unless everyone using it is some git god that runs into edge cases left and right... maybe my workflow is just not that complicat…

It's not the only improvement though, depending on your workflow.

Another thing you can do is work on multiple branches at the same time. See: https://ofcr.se/jujutsu-merge-workflow

Re: Jujutsu (jj), a Git compatible VCS

#18

Post by edflsafoiewq »

MarceColl wrote: post #15
cupofjoakim wrote: post #2

I'm still unsure of why I'd want to move to jj from git. My ideal git workflow is pretty simple: 1. `git switch -C new-branch` 2. Make changes, time passes 3. `git add .` 4. `git commit -m "Description of changes made"` 5. `git fetch && git rebase origin/main` 6. `git push` 7. Make pr to main If main is out of date I rebase again to update. This to me feels pretty light weight and is not a hinderence in any way on my…

And what are the steps when you work on 3 things at the same time (you are working on PR #2 + fixing issues in PR#1 + a hotfix needs to be deployed for an issue)? Or when you need to continue fixing things on the PR? On the absolute happy path what you do above is the same I do, where jj shines is when you het out of the happy path.

Switch to branch for thing 1, work on it, commit, switch to branch for thing 2, work on it, commit, ...

Re: Jujutsu (jj), a Git compatible VCS

#19

Post by eviks »

zug_zug wrote: post #13
ocular-rockular wrote: post #4

Earlier quoted context omitted.

But why build a whole VCS around that one use case? I looked through the docs and honestly it looks like it complicates life instead of making it easier. edit: everyone is so focused on the "single use case" part and not the fact that it looks more complicated and verbose than regular git. Unless everyone using it is some git god that runs into edge cases left and right... maybe my workflow is just not that complicat…

Moreover, even if it was say 15% better than git (and I doubt it is), the overhead of moving a whole industry across VCs is billions of dollars of loss. Every single engineer has to start over in their mastery experience by learning all the new quirks and issues, and all the tools, libraries, pipelines need to be rewritten. IMO better to support the dominant tooling than invest in fracturing one of the few areas wher…

It's also billions of dollars of gain: every single future engineer won't have to waste time due to 13% worse design.

But jj supports git as a backend, so not clear what fracturing you mean, do people using magit front-end fracture?

Re: Jujutsu (jj), a Git compatible VCS

#20

Post by fallingsquirrel »

neandrake wrote: post #8
lawn wrote: post #3

Earlier quoted context omitted.

One advantage is that jujutsu tracks merge conflicts so you don't end up in a situation where you'll have to resolve the same conflict more than once, which may sometimes happen with git.

Git’s rerere functionality should address this, right? https://git-scm.com/book/en/v2/Git-Tools-Rerere

I'm not a heavy jj user. But as I understand it, git-rerere is bolted on top and not well integrated. It just stores resolutions locally on each machine in .git/rr-cache. You need extra steps to share resolutions between contributors. https://stackoverflow.com/questions/12566023/sharing-rerere-...

In jj, resolutions are first-class objects—treated the same as any normal commit, pushed/pulled like normal, etc.

Post reply on HN