4 ms·

This particular tip is basic. It just describes how to copy changes from one branch to another with one kind of rebase. But there's always someone who is learni

This particular tip is basic. It just describes how to copy changes from one branch to another with one kind of rebase. But there's always someone who is learning git for the first time and may not even know how it's used. Git is simple enough and has features and capabilities that jj does not have. Contrary to popular belief, git is not hard to use. I refuse to use any "simpler" system that is slower or less feature-rich than git. I don't even want to learn another commit graph model, because git's model is very good. About 95% of what people like yourself call "git nonsense" consists of useful features that many people would be annoyed to not have. I believe that a large number of git or general VCS users have no idea about commit hygiene. They have not had to cherry-pick or edit commits, and have no idea what to do about conflicts. To people like that, git's features and methods will appear especially foreign. I looked over jj specifically many moons ago and concluded it would annoy me and not function at my job. I forgot what the reasons were. One reason was most likely because I need submodules and worktrees to work. I just looked at its FAQ, and saw a bunch of nonsensical new terms as well. Nothing is more compatible with git than git itself, and I am very satisfied with how well git works for me.

steveklabnik 11mo ago
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.
- wakawaka28 11mo ago
  What is the most useful feature of jj that you think git doesn't have?
  - martinvonz 11mo ago
    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.
    - wakawaka28 11mo ago
      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.
      - martinvonz 11mo ago
        > 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).
        wakawaka28 11mo ago
        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.
  - steveklabnik 11mo ago
    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.
    - wakawaka28 11mo ago
      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.
      - martinvonz 11mo ago
        > 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.
        wakawaka28 11mo ago
        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.
martinvonz 11mo ago
> 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.
- wakawaka28 11mo ago
  >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.
  - martinvonz 11mo ago
    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 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-v1-0-9b77c32688fe@pks.im/ https://lore.kernel.org/git/20250819-b4-pks-history-builtin-...).

steveklabnik 11mo ago

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.

wakawaka28 11mo ago
What is the most useful feature of jj that you think git doesn't have?
- martinvonz 11mo ago
  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.
  - wakawaka28 11mo ago
    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.
    - martinvonz 11mo ago
      > 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).
      - wakawaka28 11mo ago
        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.
- steveklabnik 11mo ago
  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.
  - wakawaka28 11mo ago
    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.
    - martinvonz 11mo ago
      > 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.
      - wakawaka28 11mo ago
        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.

martinvonz 11mo ago

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

wakawaka28 11mo ago
>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.
- martinvonz 11mo ago
  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 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-v1-0-9b77c32688fe@pks.im/ https://lore.kernel.org/git/20250819-b4-pks-history-builtin-...).