martinvonz

If I may ask, how much time have you spent trying to learn use jj? I ask because I've seen a strong tendency for people to who have never used it to argue against it. I see much less arguments against it from people who understand both Git and jj well. But that's just my impression; I may of course be wrong.

I agree, but that doesn't seem relevant. I did not say the jj automatically resolves conflicts.

> To me that counts as commit splitting

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}

> Ok, but then what was your point?

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^

The other case I mentioned was if you want to split a commit on another branch. Then you have to insert some additional commands in that sequence. As I said, I know how to do this with Git. I just find it easier to do with jj, where it's `jj split -r xyz` to split commit xyz, whether it's the current working copy, an ancestor commit, or on an unrelated branch.

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

Those were rhetorical questions. I know how to use Git. Sorry that I was unclear.

I have used both Git and jj. I find it easier in jj.

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

You can do that with just `jj split` too. The FAQ entry you linked to is for when you accidentally amended a commit and now you want to restore the bookmark to the old commit and move the changes you amended into a new commit on top instead.

That depends on the forge and the configuration of the forge. See the parent of the comment you replied to. Not everyone uses squash merge.

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

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

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?

Mostly, yes. It also covers changes to the working copy (because jj automatically snapshots changes in the working copy). It's also much easier to use, especially when many refs were updated together. But, to be fair, it's kind of hard to update many refs at once with Git in the first place (there's `git rebase --update-refs` but not much else?), so undoing multiple ref-updates is not as relevant there.

You can specify a commit, yes, but how do you remember your set of unnamed commits? Once HEAD no longer points to a commit, it will not show up in `git log`.

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.

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