Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Awesome-Jj: Jujutsu Things

github.com

Post reply on HN
Print view View original

21–30 of 30 posts

Re: Awesome-Jj: Jujutsu Things

#21

Post by 1718627440 »

martinvonz wrote: post #20
1718627440 wrote: post #19

Earlier quoted context omitted.

Sounds like "git reset" to me. Not sure, if it is, but this sounds to be easier in git.

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?

> `git reset` by itself doesn't split a commit AFAIK. You need to then `git add -p` and `git commit`

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 @
> And what happens if you had other changes in the working copy first?

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.

Re: Awesome-Jj: Jujutsu Things

#22

Post by martinvonz »

1718627440 wrote: post #21
martinvonz wrote: post #20

Earlier quoted context omitted.

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?

> `git reset` by itself doesn't split a commit AFAIK. You need to then `git add -p` and `git commit` 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 @ > And what happens if you had other changes in the working copy first? Do something with them. Put them in a commit, put them into a commit in the global stack of tod…

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

Re: Awesome-Jj: Jujutsu Things

#23

Post by 1718627440 »

martinvonz wrote: post #22
1718627440 wrote: post #21

Earlier quoted context omitted.

> `git reset` by itself doesn't split a commit AFAIK. You need to then `git add -p` and `git commit` 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 @ > And what happens if you had other changes in the working copy first? Do something with them. Put them in a commit, put them into a commit in the global stack of tod…

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

> `git reset` by itself doesn't split a commit AFAIK.

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?

Re: Awesome-Jj: Jujutsu Things

#24

Post by martinvonz »

1718627440 wrote: post #23
martinvonz wrote: post #22

Earlier quoted context omitted.

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

> `git reset` by itself doesn't split a commit AFAIK. 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 d…

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

Re: Awesome-Jj: Jujutsu Things

#25

Post by 1718627440 »

martinvonz wrote: post #24
1718627440 wrote: post #23

Earlier quoted context omitted.

> `git reset` by itself doesn't split a commit AFAIK. 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 d…

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

> Correct me I'm I'm wrong but I think were talking about using `git reset HEAD^` for splitting a commit.

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 @~
If you want to do it with rebase:

    git commit -m tmp
    git rebase @~2 # break after first commit
    git reset --soft previous-version
    git commit -C @
    git rebase --continue
    git reset @~
More idiomatic, due to using the global list of todo commits:

    git rebase -i @~ --autostash # break after first commit
    git reset --soft previous-version
    git commit -C @
    git rebase --continue
You can drop the rebase, when it is really the commit in HEAD you want to split.

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
This will even do what you wanted and just reuse the same commit message without asking.

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.

Re: Awesome-Jj: Jujutsu Things

#26

Post by sgjennings »

forgotpwd16 wrote: post #18
DanOpcode wrote: post #7

I started to use JJ during the summer, and now I'm hooked. It feels much easier to do things such as reorder, squash and split commits, as well as change commit message.

How easier than `git rebase -i`? Running this command, opens your editor of choice with this text & an extensive help commented out at the bottom: pick 5340360 # First commit. pick 12ccd8a # Second commit. pick a2b6a59 # Fourth commit. pick 2a648f2 # Commit #4. pick 6bb5d98 # Commit #5. pick af1f2fe # Commit #6. pick 7e99e85 # Commit #7. pick 7567b18 # Commit #8. pick c23819d # Commit #9. pick 50941da # Commit #10. Y…

I am quite comfortable with `git rebase -i` and I still prefer jj.

Most importantly, I get in this situation less often in the first place. Because reodering and squashing commits can be done with an easy command[1], I tend to squash or rebase as I think of it instead of batching it up to do all at once.

Many times, I don't need to manually target which commit to squash into at all, because I can be editing at the tip of the branch, then use `jj absorb` to automatically squash all my changes down into the commits where they belong.[2]

And `jj undo` is just easier to use than the reflog[3]. While reading the reflog you posted, I have to mentally replay each commit step by step. But really, if I messed something up, it's most likely I want to just go back to `HEAD@{31}`. `jj rebase` is atomic, so the whole thing is undone with one invocation of `jj undo`.

[1]: https://docs.jj-vcs.dev/latest/git-experts/#automatic-and-sa...

[2]: https://docs.jj-vcs.dev/latest/git-experts/#jj-absorb-makes-...

[3]: https://docs.jj-vcs.dev/latest/git-experts/#undo-is-more-pow...

Re: Awesome-Jj: Jujutsu Things

#27

Post by i_dursun »

nchmy wrote: post #17
Hasnep wrote: post #13

I didn't enjoy using JJ for the first day or two until I discovered jjui, now I do probably 95% of my interactions with jj through jjui.

Jjui is incredible. I keep shouting it from every rooftop that I find. So good, in fact, that I'd argue it should be made an official TUI

@nchmy You’re probably the biggest evangelist I’ve ever met.

Re: Awesome-Jj: Jujutsu Things

#28

Post by jauntywundrkind »

skydhash wrote: post #14
jauntywundrkind wrote: post #10

Earlier quoted context omitted.

I'd been concerned about that initially, but setting up some gitgnores made this a complete non problem for me. .scratch/ for a lot, *.scratch, and ig-*. It's also so easy to go back to the change latter and remove the files (after they're already copied elsewhere, or just operations log to go get) that it's really not a problem to just let stuff get in your commits. In git there's such a strong incentive to do thing…

> In git there's such a strong incentive to do things right, to make clean commits. There is no such. There are a lot of tools to manipulate commits and WIP, such as the stash, rebase, cherry pick, extracting and applying patch. You only need clean commits for review and the main branch because that helps the whole team. Your local copy can be as messy as you want to.

The incentive for me is just that it's not the most fun to use git's rebase tools to move things between commits. I'm pretty OK at rebase, but I still would way way rather not try to rebase move a file from one commit to another. And if I did, I'd probably do something hacky to copy the file out rather than try to use git to checkout the file from a rev.

Where-as jj makes rework operations, IMO, basically easy enough (after a couple weeks of use to) that I worry much less about making the right commit the first time.

Re: Awesome-Jj: Jujutsu Things

#29

Post by 1718627440 »

1718627440 wrote: post #25
martinvonz wrote: post #24

Earlier quoted context omitted.

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

> Correct me I'm I'm wrong but I think were talking about using `git reset HEAD^` for splitting a commit. 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…

Yet another way is to duplicate the commit and apply the partial reverse to the first one. I think this is what matches theory the most, and is what I essentially end up doing.

Re: Awesome-Jj: Jujutsu Things

#30

Post by nchmy »

i_dursun wrote: post #27
nchmy wrote: post #17

Earlier quoted context omitted.

Jjui is incredible. I keep shouting it from every rooftop that I find. So good, in fact, that I'd argue it should be made an official TUI

@nchmy You’re probably the biggest evangelist I’ve ever met.

That somehow feels like an insult!

Keep up the great work

Post reply on HN