submodules aren't native with jj, you use git commands to manage them, and it works fine. Eventually there'll be some sort of native support.

worktrees are called "workspaces" in jj, but are the same.

A lot of people find jj easier to have good commit hygiene with, and find it simpler and more powerful, not less. But that said, if you're happy with git, you should continue to use it.

What is the most useful feature of jj that you think git doesn't have?

For me, that's probably jj undo, just because it makes everything else so nice to just give a try. I really don't worry about making mistakes.

But for me, it's not so much features that git doesn't have, it's that the core is factored in a way that's more focused and orthogonal. The stuff that I used to like to do with git is even easier and more straightforward with jj. This is more of the result of a bunch of different design decisions and how they fit together rather than just some specific feature that's great.

Sounds like jj just simplifies the interface of some git commands, mainly. After talking to some jj enthusiasts here, I think we just have a different perspective about what needs to be simple and even what constitutes simple. There is probably some lingering unfamiliarity with git among jj enthusiasts as well. I don't want to teach git to people who are not programmers, but I wouldn't want to teach any programmer's VCS to them honestly. If you are a programmer, I think git is the best.

> There is probably some lingering unfamiliarity with git among jj enthusiasts as well.

I've heard this a few times. But from what I've seen, it seems like often it's the Git enthusiasts who seem to be unfamiliar with jj. I haven't heard from anyone who used jj for a few months and knew it well and then switched to Git.

I have never used jj, nor met anyone who used it in person. Given how new it is, you just won't find enough people who used it at all. I think git is like the vim of VCS systems and like vim there are some people who just don't think that way. I think jj might be more like emacs in that it has the initial appearance of being simple, but when you get into it more deeply you realize that it is not so simple after all.

I have used other VCS systems that made similar claims about being simpler, such as Mercurial. I think I got to be fairly expert at Mercurial before becoming expert at git, and even used it to interact with SVN repositories. (I've also used git for SVN. This is another thing git does better.) After actually learning git past the first few commands, I would never go back to Mercurial. I don't want to mix and match systems either. There are things I want git to do better, but I would not call these simple feature requests... They are more along the lines of advanced features that need to be extended or polished.

I can pick only one? Perhaps automatic rebasing then, i.e. that all descendant commits and bookmarks (branches) are automatically updated when you rewrite a commit, e.g. by amending into it.

I don't think I would want to rewrite all branches based on rewriting one of the ancestors of those branches. This only makes sense for local branches, and I just never have such a set of branches. Most rebases are to get ahead of upstream work, and I can't rewrite that. The rest are to rewrite commits that I made, and I collapse all those commits down periodically anyway. In the rare case I might be able to use this feature, rebasing all the other branches (realistically, probably like 1 or 2) would be easy enough to do manually with the feature described in this post. Rebasing and touching up commits is very easy with git interactive rebase. There are also features to automatically reorder commits with, e. g., `git commit --fixup` and `git rebase --autosquash`.

If you have others in mind then go ahead lol. I was just trying to make it easy.

> I don't think I would want to rewrite all branches based on rewriting one of the ancestors of those branches. This only makes sense for local branches, and I just never have such a set of branches.

Yes, it's only meant for local branches. When I used Git, I had a script for rebasing dependent branches. I remember that a coworker had written a similar script.

I think jj is generally more useful for people like me who often have lots of independent and dependent work in progress. If you mostly just have a one review at a time, there's much less benefit. Perhaps I would say that `jj undo` might be the most useful feature for users with simpler development (yes, I know about the reflog, but see the video I linked to in the other message).

I think this is generally only useful, if these branches don't need any other change for updating the ancestor. When they need than you need to work on the branch anyway and rebase other commits or add new ones on top, so you gain nothing compared to "rebase --onto" for each branch separately.

If you don't have anything to update then that would be somewhat pointless to me. You can also just rebase them, when you start working on the branch again or want to merge them.

--

For me branches also represent features, that should have clear boundaries, so when I work on one feature and that means, I need to rebase another one on top instead of being able to just merge them later, this indicates a spaghetti codebase where the interfaces between features are not properly defined and things depend on internals of other things.

>For me branches also represent features, that should have clear boundaries

I try to do this too but I often end up in situations where I have multiple incomplete (in testing, not merged) features with outstanding patches. Instead of one branch per topic, I end up with one branch for a bunch of related stuff. I then rebase and pause at the feature boundaries to do more testing. Sometimes, if I find myself doing this a lot, I will use the `exec` feature of `git rebase` to automate my testing.

I think rewriting all related branches can cause problems. It would be really weird to do interactively for one thing. The other problem is that you may have unrelated topic branches broken by such a change. If you have a broken patch X that reveals problem Y on branch Z1, but you are working on fixing that on Z2, you may lose your ability to reproduce the Z1 issue if X is fixed on every branch. What if you get conflicts on all those branches? What does this do to the reflog? Yikes! It seems more dangerous than git itself.

These complaints are very niche of course, but the problem of rewriting many branches at once is also very niche. It can cause more problems than it solves.

jj doesn't force you to resolve the conflicts immediately, so it'll just show that they're conflicted until you decide you want to go fix them.

That sounds real painful and confusing. You could end up with a bunch of conflicts in separate commits, on multiple branches, none of which you actually wanted to modify in the first place.

It’s not any different than git, the only difference is that you can choose to resolve the conflict when you want, instead of it interrupting rebase.

If you don’t want to modify a branch, then you shouldn’t rebase it, same as git.

Someone just told me that if you rewrite a commit that is an ancestor of multiple branches, it will (or can) automatically rewrite all the branches.

What does it even mean to not resolve conflicts? Your branch code and/or history is broken until you come around and fix it? If so, forcing you to fix it immediately is better. Aside from the practical implications of deferring conflict resolution, I just can't think of a reason I would do it in the first place. If a branch can't be rebased with zero work, and I don't have time to do that work, I just don't do the rebase.

Sure, my point is just that if you don’t want history re-written, you just don’t re-write it. If you have multiple descendant branches and for some reason you don’t want the children to move as well, you can move them back. It’s almost the opposite of what the article describes; instead of needing to choose to move children, children move automatically and you move ones you don’t want to back. I’ve never wanted to do this but if it happened it would be easy enough to fix.

It looks like this: when a git rebase would pause the rebase to make your resolve a conflict, jj keeps going. When the rebase finishes, if there are any conflicts, they’re displayed in the log with ?? after their ID. jj won’t let you push a branch with conflicts until the conflict is resolved. You can fix the conflict by either editing that commit directly, or my preferred way, which is to make a new change on top and then squash the resolution back in after you read it over.

So there’s a few thins about why this is useful: because children are also rebased, you can see immediately how much work, if any, you have to do. I have an alias to rebase all open branches on top of trunk, and will often pull trunk, run it, and see if I have any work to do to update them. “Oh, only one of my three branches needs work, I’ll work on the two that are fine first” can happen, and that third can just sit there. Or, as I said before, I could move it back on top of its old base, and the conflict disappears. Or, say I suspected none of them conflict, but all three do, and I don’t want to do it at all right this moment, I’ll just jj undo and they’re all unconflicted and back in place.

Let's say you have this (modified from `git rebase --help`):

``` A---B---C main \ D---E---F feature1 \ \---G---H feature2 \ \---I---J feature3 ```

(sorry about the formatting here. I guess you'll have to copy & paste it to read it)

What I'm saying is that if I want to fix something in D, I do `jj new D` to create a new commit on top of D. Then I make the fix, run tests, etc., and then I run `jj squash` to amend the changes into D. The descendant commits (E through J) then get automatically rebased and the feature bookmarks/branches get updated.

I didn't follow what you about it other changes needed for updating the ancestor. Can you explain in the context of this example?

So what I am saying is that after you created D', it is true, that you need to run `rebase --onto` in git, while it is automatic in jj. But I think updating feature2 and feature3 is only really necessary to do now, when you want to change something in G-J also. If you don't and it wouldn't cause merge conflicts at all (logical and physical) then you could also just do this when you work on top of H or J the next time, so it wouldn't actually cause any more work in git compared to JJ.

--

The other thing I am saying is that I don't really let features depend on each other, I let them specify the API between them first and then develop them independently. Otherwise it is easy to violate boundaries. So the ideal is that any of G,H and I,J works with D,E,F and vice versa. Of course that is tangential and it doesn't always work that way.

Hacker News doesn't support Markdown, but you can indent lines by two spaces to get it formatted like code: https://news.ycombinator.com/formatdoc

I think you're right about people having trouble with `git reset` but it's really not that hard. There is also the newer `git restore` command which is somewhat easier. There are many individual functions which have an inverse, so the word "undo" might not be a good choice for git. You could make a `git undo` that does the `jj undo` logic with the reflog very easily. I'm not sold on the simplifications yet but to be fair I'm not trying to learn it either lol.

> I don't even want to learn another commit graph model, because git's model is very good.

I agree. That's why jj uses practically the same model. That's how Git can quite easily be used as a backend.

> I just looked at its FAQ, and saw a bunch of nonsensical new terms as well.

Like what? Perhaps we can improve it.

>Like what? Perhaps we can improve it.

I'm sure it is stuff that makes sense to a jj user. Since I have not read the manual, it is nonsense to me. I'm just drawing attention to the fact it's a different set of non-obvious terminology and features as compared to git. I'm sure anyone who read the manual for either tool could figure it out. The trouble with git is that people don't read the manual, and hardly try to do anything with it, then loudly complain about it being tricky. Anything as complicated as version control is going to be tricky if you don't read the manual. I don't think making another tool entirely is the right solution. Perhaps a different set of git porcelain tools could help, or some git aliases. Maybe better documentation too. But some people just can't be pleased.

This seems to be a common misconception, that many jj users don't understand Git. Most jj users I know were pretty good at Git as far as I can tell. Perhaps you'll find this recent video where Scott Chacon talks about Jujutsu interesting: https://www.youtube.com/watch?v=PsiXflgIC8Q. Scott is a GitHub cofounder, author of Pro Git, and now runs GitButler.

> I don't think making another tool entirely is the right solution.

I considered making the changes to Git but the changes I wanted to make would make the UX so different that it would basically mean introducing a whole parallel command set to Git. I figured it would take ages to get Git to that state, if I could sell the ideas to the Git community at all. By the way, the video above talks about an proposed `git history` series of commands inspired by Jujutsu (also see https://lore.kernel.org/git/20250819-b4-pks-history-builtin-...).

Well, if I had to guess, many current jj users are git veterans who are tired of watching git noobs struggle. The other segment is the git noobs themselves, who never really bothered to learn git and have a deep aversion to reading the manual and doing basic experiments. Just a guess, though.

I think I saw Scott Chacon talk about his git config file and advanced git features. Whoever it was, it mentioned GitButler. That was a good talk. I would certainly expect someone like that to have a lot of interest and expertise in git. But it seem to me that there is also a potential commercial angle to making a new/alternative VCS.

I looked at the mailing list entry you linked to about `git history` commands and thought to myself, it sounds all wrong and redundant. `git history` sounds like too broad of a name for one thing. I'd want to have it be `git <verb>` instead. All the operations listed can be done with rebase:

- `git history drop`: Instead, rebase interactively and drop one or more commits.

- `git history reorder`: Interactively rebasing makes this work already.

- `git history split`: Insert a pause in the interactive rebase. Do a soft reset or something to the previous commit, and use `git restore` to unstage the changes (there might be a more efficient way to do this in one step, but idk). Then, do `git add -p` to add what you want, commit, as many times as you want to split the patch. Then continue the rebase.

- `git history reword`: There is a reword option in interactive rebase mode, and also a fixup-like option to do it as well if you want to postpone the rebase.

- `git history squash`: Rebase can do this now in multiple ways.

Rebasing is not that hard. It is the Swiss Army knife of VCS tools. Once you realize that you can just break in the middle of a rebase and do nearly anything (except start another rebase), the world is your oyster. We don't need to spam people with many more single-purpose tools. We need people to understand why the way things are is actually pretty damn good already, if only they read the manual.

> Rebasing is not that hard.

No, but it takes like 5 manual operations to do something as simple as amending my changes to a commit that's 3 parents before my current HEAD.

There's simply no excuses for git being this unusable for the very simplest operations I do day to day.

Amending a commit behind HEAD is not a simple thing in general. You can have conflicts. When it can be done simply, it can be done in 2 steps with git (or less than 2, since you can amend lots of commits with one rebase). What are the 2 steps? After adding what you want, here they are:

- `git commit --fixup HEAD~3`

- `git rebase --autosquash HEAD~4`

The "less than 2 steps" part comes from fixing up more than one commit having no conflicts before the rebase. It is very common to want to stop or run test scripts at various points in the newly modified history, and rebase can trivially help you automate that (but only if you want).

Rebasing literally just does a sequence of steps in the order you specify. You can make those steps complicated, or not, without learning yet another tool. The complexity that is in the rebase tool is practically all necessary.

After using git for many years, I realize now that a lot of thought went into its design. The way it works, especially with the rebase tool, is superior to having a dozen single-purpose tools.

I don't think this particular thing is against the UNIX philosophy either. All of these operations are intimately related just like the operations that a FTP client might do. I can just imagine someone like you looking at FTP or rsync, and saying "This can be 20 different commands! Why don't they make my particular use case into its own command!" There is a place for that kind of logic, but all of the things jj supporters have proposed to me are way too niche to have their own separate commands. My commit edits are complicated, and `git rebase` makes them super simple.

Maybe you know this already but it's `jj squash --into @----` whether there are conflicts or not.

I didn't know that, but I'm not surprised that this is possible because jj allows you to defer conflict resolution. I for one prefer git's step-by-step rebase model that makes you address conflicts at the time of the rebase. If you aren't ready to address conflicts, you shouldn't be mucking around with the commit history yet. Also, if you turn on rerere, then you can also (usually) avoid fixing the same conflicts multiple times.

The author of `git history` is a GitLab employee and prolific Git contributor. I think he knows how `git rebase` works.

I think the issue that wakawaka28 has and I also have is, that I don't think we should have lots of "wizards" for specific high-level operations users want to do. Then we will only end up with hundreds of commands, that all do slightly the same. Also it will train (new) users to complain about adding yet another command to do what they want, instead of letting them learn how to combine the already existing commands.

What we should do instead is provide a bunch of primitives, that as high-level are as possible so to not end up with duplicate commands, which is what git does currently. `git history` as a name is somewhat pointless, since the whole point of git is to produce and modify the history. In that sense `git history` already exists, it is called `git`.

I think the issue newbies have is not that git commands are hard per se, but that they don't think in terms of modifying the graph yet, or that they don't know which primitives are available.

For what it's worth, I mostly see jj as being to git what you describe in your first few paragraphs. That's why I like it so much.

That makes his decisions all the worse and in poor taste IMO, because he ought to know that these use cases are well-covered already. Furthermore, I'm not talking to him. I'm talking to anyone who thinks that his patch was a good idea. I am not going to be dazzled by brand names in this conversation lol.

Lol you could just say you disagree. Is it SO alien to you that users of the most popular VCS in the world might like it the way it is? After arguing with you guys, the only deep fact coming through is that people like you get irrationally optimistic about new tools, after the old favorite doesn't appeal to you for some reason.

Yeah your parent is being combative all over this thread, there’s just no reason for it.

For whatever it’s worth, the general stance of the project and most of the community is “git is good, we like jj more, but you should use whatever you prefer.” Lots of us loved git before jj came along, and there’s a lot of cross pollination between the two projects. I hope your parent takes the feedback and chills out.