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

51–60 of 117 posts

Re: Jujutsu (jj), a Git compatible VCS

#51

Post by steveklabnik »

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…

For me, jj is better than git because it has achieved something of a holy grail: it is both simpler and more powerful, at the same time. It achieves this by having more cohesive primitives.

Take the index. I love(d) git’s index. It is a powerful way to build up focused commits. Jj does away with the index, yet gives you equivalent power. How? Because instead of a separate index concept, jj has a special name for a commit representing the index: @. Files are (by default) automatically tracked and included in @. Just like how you’d git add -p, you create a new commit for your work, then create a commit on top of it. As you work, @ gets built up with your code, and when you’re ready, jj squash (with various flags or paths to control exactly what gets added) to move them into your parent, “real” work commit.

So if it’s the same, why is it better? Because we’ve reduced the number of states: instead of dirty, staged, and committed, you just have committed. And with that, commands are simpler: no distinction between —hard or —soft for something like git reset, everything just operates on committed state. This means you can bring the full set of tools to manipulate commits to bear on your index!

The same goes with stashing: because heads are allowed to be detached, to use the git terminology, we don’t need a special stash concept: create a new commit that’s forward of where you’re working to “stash” your changes in there until you need them.

These are two simple examples, but it’s really about how everything fits together into an extremely powerful and cohesive tool.

Re: Jujutsu (jj), a Git compatible VCS

#52

Post by keybored »

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…

> 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 issues outlined.

You would have thought? Plugins? Git doesn’t have plugins to my knowledge. Hooks are not plugins for security reasons. Meaning you can’t distribute hooks, have people install them and call it an extension.

Then, assuming that they could just make Git better. Are they interested in supporting all of Git plus their new work? Why would they be?

Re: Jujutsu (jj), a Git compatible VCS

#54

Post by stouset »

tonyfinn wrote: post #42
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…

I commented on exactly this elsewhere in the thread. It’s hard to understate how insanely useful it is to be able to painlessly edit earlier history even when there are later threads of work based on it.

Also in my experience everyone says “my default workflow is easy” when you talk about an alternative VCS but in every other context they complain about how often that workflow starts getting exceptional: rebase conflicts, stash conflicts, WIP commits, uncommitted work accidentally blown away, etc.

Re: Jujutsu (jj), a Git compatible VCS

#57

Post by stouset »

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…

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

Because the git workflow causes a lot of the difficulty and fixing it involves making a new concept: mutable changesets with a unique id which are built on top of immutable commits.

jj isn’t just some bugfixes or a few porcelain improvements, it deeply changes the way you approach things. And there’s a pretty decent amount of unlearning of subtly-broken concepts you need to do.

None of that could ever make its way into git.

Re: Jujutsu (jj), a Git compatible VCS

#58

Post by dsissitka »

stouset wrote: post #50
JTyQZSnP3cQGa8B wrote: post #46

Earlier quoted context omitted.

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

> Every time you run a `jj` command a snapshot of your local changes is made.

I think that's going to be pretty divisive. For projects where your input is here, your output is there, and that's that I imagine it's fine. Getting people to implement one of the workarounds to avoid junking up the repo feels like a huge ask.

Re: Jujutsu (jj), a Git compatible VCS

#59

Post by stouset »

KerrAvon wrote: post #34
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,…

Merges were so, so painful in SVN, though. Maybe SVN improved towards the end of its life? I remember everyone went well out of their way to avoid needing to merge until git, because it could take hours to resolve a heavily-conflicted tree.

People complain constantly about how painful git is when their simple workflows break down. It is legendarily complicated and difficult to use.

But when an alternative comes along and long-term git users try to tell people how much better it is? Everyone immediately forgets all their issues and frustrations. It’s honestly kind of bizarre.

Re: Jujutsu (jj), a Git compatible VCS

#60

Post by BeetleB »

oxidant wrote: post #36
MarceColl wrote: post #21

Earlier quoted context omitted.

Do you stash or create a commit with potentially partial work? What do you name that commit?

`git add .`, `git commit -m "wip: some note about what I was doing" Then checkout the new branch and do my work. When I come back, `git reset --soft HEAD^`, and continue

Your comment is a great ad for not using git.
Post reply on HN