`git reset` by itself doesn't split a commit AFAIK. You need to then `git add -p` and `git commit` (and recover the commit message from the old commit). And what happens if you had other changes in the working copy first? Or if you want to split a commit that's not at HEAD?

If you want to generate two commits with the exact same message, then do:

    git checkout combined-commit
    git reset --soft previous-version
    git commit -C @

Do something with them. Put them in a commit, put them into a commit in the global stack of todo commits or tell git to do that automatically.

> Or if you want to split a commit that's not at HEAD?

Check it out or do a rebase.

Git reset splits a single commit, into two "things", another commit with the first part and a second part that is put into a version prepared for a commit (--soft), prepared for further editing (--mixed) or thrown away (--hard). To me that counts as commit splitting, but it may not match with JJ terms. Also splitting into two commits with the same commit message doesn't sound quite useful to me, so the default of Git two require a second commit message is sensible to me.

> Those were rhetorical questions.

Ok, but then what was your point?

Correct me I'm I'm wrong but I think were talking about using `git reset HEAD^` for splitting a commit. That will move the current branch backwards one step. With `--mixed`, it will also move the index back one step, so the index is empty (relative to HEAD) and the working copy has the combination of changes that were in the previous HEAD commit and the working copy (relative to the previous HEAD). I think that's more like squashing than splitting because we have fewer "things" after: we have one commit fewer (the previous HEAD commit may of course still be reachable from another branch, in which case we still have the same number of "things" afterwards). It's similar with `--soft` and `--hard`, except that the old changes end up in a different "thing".

At a less technical level, the point of splitting a commit is to end up with some of the changes from one commit in a new commit and the rest of the changes in another commit. That's what meant when I said "`git reset` by itself doesn't split a commit", because you need to do something like this:

  git reset HEAD^
  git add -p
  git commit -C HEAD@{1}

Just that additional steps are needed.

For example, if you wanted to split the HEAD commit but you had already started working on a new commit so have some changes in the working copy, then you might instead have to do something like this:

  git commit -m tmp
  git rebase -i HEAD^^ # Use the "edit" action for the first commit
  git add -p
  git commit -m first
  git rebase --continue
  git reset HEAD^

(Take my Git commands with a grain of salt because I haven't used Git in 10 years.)

I wasn't. I wanted to do the same as in the FAQ entry we are talking about, so I wanted to reset it to an older commit representing the same change (i.e. before an amend that we are now reverting). This is likely in a rebase, but we can always rebase later and only do the splitting now.

> With `--mixed`, it will also move the index back one step, so the index is empty (relative to HEAD)

Yes and this is the default (without any flag).

> That's what meant when I said "`git reset` by itself doesn't split a commit", because you need to do something like this:

That's what the `--soft` is for, then `git reset` does not touch the index.

> Just that additional steps are needed.

The only "additional" step required is specifying a commit message, which, as I said earlier, to me is a sensible default.

What I suggested applied on this case would be:

    git commit -m tmp
    git checkout @~
    git reset --soft previous-version # which you get from the reflog
    git commit -C @
    git rebase @~ branch-you-were-on --onto=@  # not of much use, when you only have a single commit you are throwing away in the next step, but when you are editing something earlier, this is likely what you want.
    git reset @~

    git commit -m tmp
    git rebase @~2 # break after first commit
    git reset --soft previous-version
    git commit -C @
    git rebase --continue
    git reset @~

    git rebase -i @~ --autostash # break after first commit
    git reset --soft previous-version
    git commit -C @
    git rebase --continue

Actually what you can also do, but this doesn't use reset, is this:

    git rebase -i @~ --autostash
    # add as the first line:
    pick previous-version
    git rebase --continue

Honestly, what I do most of the time to split commits (when there isn't an older version I want to split it to) is to just amend and then unselect the changes I don't want with the cursor.

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 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 agree that Git could gain an operation log. I haven't thought much about it but it feels like it could be done in a backwards-compatible way. It sounds like a ton of work, though, especially if it's going to be a transition from having the current ref storage be the source of truth to making the operation log the source of truth.

I also tend to have the builtin GUI log equivalent (gitk) open. This has the behaviour, that no commit vanishes on refresh, even when it isn't on a branch anymore. To stop showing a commit you need to do a hard reload. This automatically puts the commit currently selected into the clipboard selection, so all you need to do is press Insert in the terminal.

> It sounds like a ton of work, though, especially if it's going to be a transition from having the current ref storage be the source of truth to making the operation log the source of truth.

I don't think that needs to be implemented like this. The only thing you need to do is recording the list of commands and program a resolver that outputs the inverse command of any given command.

When I’m exploring a problem I end up with complex tree of many anonymous branches as I try different solutions to a problem and they all show up in my jj log and it’s so easy to refer to them by stable change ids. Often I’ll like part of a solution but not another part so I split a change into 2 commits and branch off the part I like and try something else for the other part. This way of working is not nearly as frictionless with git. A lot of times I do not even bother with editor undo unless it’s just a small amount of undoing because I have this workflow.

Git is to jj like asm is to C: you can do it all with git that you can do with jj but it’s all a lot easier in jj.

Within a day of switching I was fully up to speed with jj and I never see myself going back. I use colocated repos so I can still use git tools in my editor for blaming and viewing file history.

Sure even rebasing a complex tree in git can be done by creating an octopus merge of all leaf nodes and rebasing with preserve merges but like that’s such a pain.

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.

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.

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

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.

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.

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

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

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

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

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.

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.

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

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.

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.

``` 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?

--

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.

Is the scenario that you make many changes in the working copy and then run `git add -p` a few times until you're happy with what's staged and then you `git commit`? With jj, you would run `jj split` instead of the first `git add -p` and then `jj squash -i` instead of the subsequent ones. There's no need to do anything instead of `git commit`, assuming you gave the first commit a good description when you ran `jj split`. This scenario seems similarly complex with Git and jj. Did you have a different scenario in mind or do you disagree that the complexity is similar between the tools in this scenario? Maybe I'm missing some part of it, like unstaging some of the changes?

It is in number of commands ran, but there's a few annoyances around changes getting into the repo automatically.

There's a lot of git commits coming from jj's constant snapshots. Maybe this is a good thing overall, but it brings some silly issues,

What to do when data that shouldn't leave the dev machine gets to the repo? I'm thinking secrets, large files, generated files. - Leaking secrets by mistake seems easier. - Getting large files/directories into the git snapshots might degrade git's performance.

It seems that you need to be diligent with your ignores or get forced to learn more advanced commands right away. I guess there's a more advanced history scrub command around though.

This wasn't what I was talking about, I meant that you should create a bare repo and push to it, not that you work directly in a directory in Dropbox.

      --update-refs, --no-update-refs
           Automatically force-update any branches that point to commits that
           are being rebased. Any branches that are checked out in a worktree
           are not updated in this way.

           If the configuration variable rebase.updateRefs is set, then this
           option can be used to override and disable this setting.

Yes, this is something, that JJ provides and Git does not.