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

41–50 of 117 posts

Re: Jujutsu (jj), a Git compatible VCS

#41

Post by skybrian »

yuppiepuppie wrote: post #26
emacsen wrote: post #11

Earlier quoted context omitted.

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,…

I get what you are saying about the nicer workflows for those cases. However, why would the contributors to jj not just try to make git better by addressing these weaknesses? I’m not being glib, just that it puzzzles me when a new oss comes out that does the same thing as another tool but a a bit different. I would have though that there is a way to have a git plug-in or even a way to contribute to git to enhance the…

In some sense they already are making git better since that’s the data format that the tool supports.

Also, some of the UI improvements or even protocol improvements might make it into git eventually.

I’m skeptical about it being worthwhile to switch to a new backend. Maybe it would work if it’s just local, but a lot of IDE plugins and other tools would need to be written, and git has lots of inertia.

Re: Jujutsu (jj), a Git compatible VCS

#42

Post by tonyfinn »

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…

Author here: The biggest benefit for me is the ability to work on change N+1 (or sometimes even N+2 also) while change N is being reviewed without subjecting myself to constant merge resolution if I need to update change N due to e.g. reviewer feedback, issues in pipelines, etc. `rerere` helps somewhat, but the flow is much nicer when I can just rewrite one commit and everything downstream updates itself.

The others are also listed in "the good" section of the article, but that's the biggest one. How much of a benefit that is for you will really depend on your usage patterns - maybe it's solving a problem you don't have. But the nice thing is since it's git compatible, people for whom this solves a problem can use jj, without having to migrate their whole team/company from git, unlike other solutions like fossil, darcs or pijul.

Re: Jujutsu (jj), a Git compatible VCS

#43

Post by sebastialonso »

emacsen wrote: post #11
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,…

Point 3 is dishonest, imo.

jj has no evidence today to support the idea that it will be a main tool in the future. An even heavier burden of proof comes from the idea that it could be adopted by mainstream forges, so it's certainly not an argument on how jj is better than git.

Re: Jujutsu (jj), a Git compatible VCS

#45

Post by dietr1ch »

yuppiepuppie wrote: post #26
emacsen wrote: post #11

Earlier quoted context omitted.

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,…

I get what you are saying about the nicer workflows for those cases. However, why would the contributors to jj not just try to make git better by addressing these weaknesses? I’m not being glib, just that it puzzzles me when a new oss comes out that does the same thing as another tool but a a bit different. I would have though that there is a way to have a git plug-in or even a way to contribute to git to enhance the…

> why would the contributors to jj not just try to make git better by addressing these weaknesses?

Because jj isn't being built to improve git, but to allow using git at Google to work on Piper-backed code instead of hg/fig, and adding support for the abstractions that are needed to support git and piper was probably seen as free complexity on git's side.

Re: Jujutsu (jj), a Git compatible VCS

#46

Post by JTyQZSnP3cQGa8B »

emacsen wrote: post #11
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,…

> I remember plenty of people who used SVN saying why did they need to use git

I remember everyone saying “SVN is a piece of shit, I hate it, why can’t I easily create branches.” Also mixed revisions which was the worst part of it.

The jj people should really write a guide to show how it’s better than git because, so far, I’m still very confused and we’ve had that conversation on HN at least 10 times without anyone giving concrete examples.

Re: Jujutsu (jj), a Git compatible VCS

#47

Post by JTyQZSnP3cQGa8B »

mjarrett wrote: post #23
MarceColl wrote: post #15

Earlier quoted context omitted.

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.

Isn't git-worktree designed for this kind of situation, where you could open each PR or branch in its own directory and switch your editor / other tooling between workspaces without losing state between them?

You can already do that with git branches. Worktrees is a cleaner way to share history but it’s irrelevant to merge conflicts and multiple PRs.

Re: Jujutsu (jj), a Git compatible VCS

#48

Post by BrouteMinou »

yuppiepuppie wrote: post #26
emacsen wrote: post #11

Earlier quoted context omitted.

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,…

I get what you are saying about the nicer workflows for those cases. However, why would the contributors to jj not just try to make git better by addressing these weaknesses? I’m not being glib, just that it puzzzles me when a new oss comes out that does the same thing as another tool but a a bit different. I would have though that there is a way to have a git plug-in or even a way to contribute to git to enhance the…

[flagged]

Re: Jujutsu (jj), a Git compatible VCS

#50

Post by stouset »

JTyQZSnP3cQGa8B wrote: post #46
emacsen wrote: post #11

Earlier quoted context omitted.

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,…

> I remember plenty of people who used SVN saying why did they need to use git I remember everyone saying “SVN is a piece of shit, I hate it, why can’t I easily create branches.” Also mixed revisions which was the worst part of it. The jj people should really write a guide to show how it’s better than git because, so far, I’m still very confused and we’ve had that conversation on HN at least 10 times without anyone g…

And I remember everyone saying that git is confusing, that they get into states that they don’t understand and have to blow their local changes away, and that they have completely fucked their local copy more than once.

I’ll give you some concrete advantages:

1. Every time you run a `jj` command a snapshot of your local changes is made. I don’t know about you but often while I’m working on something experimental I have an idea for a slightly different approach, try it out, it doesn’t pan out, and I’m like fuck I wish I’d saved where I was an hour ago. git won’t do that for you but jj will.

2. The rebase workflow is dramatically better. Rebasing multiple commits with conflicts is excruciating. You have to fix it right here and right now but you’re in a weird repo state where you can’t easily to another commit and tweak it or look at the state of things at different times. It’s a pain in the ass and easy to get wrong. With jj there are no weird intermediate rebase states. Rebasing always succeeds and if there are conflicts you’re able to address them just by editing your changes as you would in any other situation.

3. I don’t have to make WIP commits or stash when switching between lines of work and I don’t have to remember to undo them when I come back. Your work is always committed. Stashing doesn’t need to exist any more and as a result I never have to worry about conflicts when unstashing. I never have to realize I’ve forgotten work that was stashed.

4. Named branches don’t follow you automatically. This is huge if you ever have to do some linear work that involves multiple PRs that have to be merged and deployed one by one by one. With git you have to make branch after branch after branch. And god help you if one of the earlier lines of work needs to be changed, now you have to rebase all the descendants. With jj all this work is linear. If you have to edit an earlier commit or insert a new commit inbetween two, it’s trivial.

5. And the real killer feature? I get to have all this and nobody on my team needed to change a thing for themselves.

I was a git expert. I’ve used it since before GitHub. I’ve written a barebones implementation of git from scratch. I was the guy everyone came to when they got stuck. I gave talks on git to my local language user meetup. And I will never need to touch it again.

Post reply on HN