I tried jj a few times but it seems to be incompatible with my workflow.
I tend to have lots of uncommitted files and changes that i want to keep around in this state while I move around branches and while having multiple change lists (jetbrains implementation) that I will commit at some point in time.
This loose, flexible way of using git seems hard to do in jj.
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.
1718627440 11 hours ago [-]
Sounds like "git reset" to me. Not sure, if it is, but this sounds to be easier in git.
martinvonz 11 hours ago [-]
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?
1718627440 10 hours ago [-]
> `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:
> 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.
martinvonz 10 hours ago [-]
Those were rhetorical questions. I know how to use Git. Sorry that I was unclear.
1718627440 10 hours ago [-]
> `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?
martinvonz 8 hours ago [-]
> 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.)
1718627440 47 minutes ago [-]
> 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.
benoitg 1 days ago [-]
I’m the same as the parent, auto-track = none() works perfectly for me
jauntywundrkind 1 days ago [-]
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 things right, to make clean commits. Imo one of the huge strengths of JJ is abandoning the obsession, and having far far far better tools to clean up after.
skydhash 21 hours ago [-]
> 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.
DanOpcode 1 days ago [-]
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.
forgotpwd16 13 hours ago [-]
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:
And if you messed up anything, you can always undo it by using your `git reflog`. No matter what you did, you can always go back a previous state! Each state is stored as new commit.
dbbb733 (HEAD -> master) HEAD@{18}: rebase (finish): returning to refs/heads/master
dbbb733 (HEAD -> master) HEAD@{19}: rebase (pick): Commit #10.
4bf7bcd HEAD@{20}: rebase (squash): Commit #6.Commit #8.
cdc47c1 HEAD@{21}: rebase (pick): Commit #6.
2ca48d8 HEAD@{22}: rebase (squash): Commit #5.Commit #7.
6a6fccc HEAD@{23}: commit (amend): Commit #5.
86ca5f8 HEAD@{24}: rebase (edit): Commit #5.
1259a52 HEAD@{25}: rebase (reword): Second "Hi" commit.
b33f89c HEAD@{26}: rebase (reword): Second commit.
9cefee3 HEAD@{27}: rebase (pick): Commit #4.
2448f03 HEAD@{28}: rebase (pick): Fourth commit.
5340360 HEAD@{29}: rebase: fast-forward
d1406ed HEAD@{30}: rebase (start): checkout d1406ed8145dc84695eb622bc6b3fc078e8098df
50941da HEAD@{31}: commit: Commit #10.
c23819d HEAD@{32}: commit: Commit #9.
7567b18 HEAD@{33}: commit: Commit #8.
7e99e85 HEAD@{34}: commit: Commit #7.
af1f2fe HEAD@{35}: commit: Commit #6.
6bb5d98 HEAD@{36}: commit: Commit #5.
2a648f2 HEAD@{37}: commit: Commit #4.
a2b6a59 HEAD@{38}: commit: Fourth commit.
12ccd8a HEAD@{39}: commit: Second commit.
5340360 HEAD@{40}: commit (initial): First commit.
Feel like git has a reputation for being hard even for things they're not that much.
Hasnep 21 hours ago [-]
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.
nchmy 14 hours ago [-]
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
Svoka 1 days ago [-]
I really do want to learn and love it. It seems I love all the things which are told about it, but, I think JJ has a tutorial problem. I would really want something which focuses on concepts of it rather than workflows. May be some diagrams? I know that JJ-ists think that it is very easy to understand wall of cli printed text, with ascii trees and hash prefixes in bold, but it really isn't. Especially for target audience of tutorials (folks new to JJ).
gpm 1 days ago [-]
https://jj-for-everyone.github.io is the most approachable jj tutorial I've seen. I wouldn't say it focuses on workflows, but it does take a "learn by doing" approach a bit more than the "data model first" approach it sounds like you might prefer.
It's still a young tool, it's not surprising that tutorials are a bit lacking (honestly there are surprisingly many for its age). Maybe be the change you want to see in the world and make one? (Which would be an... interesting... way to learn the tool for sure).
jiggunjer 1 days ago [-]
Same. It's how I learned Docker and Kubernetes, study the concepts, then I can ask "what's the specific command to do A,B,C" instead of an open ended "how do I do X".
viraptor 1 days ago [-]
Have you tried it yet? I found the tutorials a bit convoluted. But just giving it a go for a couple of days gave me more in practice than reading docs for a week could. It's not to say the docs couldn't be better - just maybe it's not as much of a barrier as you think.
Svoka 1 days ago [-]
Yes, I got lost when trying to sync with remote repo from two machines. I'll give it another try.
1 days ago [-]
Rendered at 08:40:11 GMT+0000 (Coordinated Universal Time) with Vercel.
I tend to have lots of uncommitted files and changes that i want to keep around in this state while I move around branches and while having multiple change lists (jetbrains implementation) that I will commit at some point in time.
This loose, flexible way of using git seems hard to do in jj.
Eg with stacked git (stg) this is just: goto, spill, and then refresh/create the stuff I want.
[0] https://docs.jj-vcs.dev/latest/faq/#i-accidentally-changed-f...
`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:
> 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.
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:
> 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:
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.)
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:
If you want to do it with rebase: More idiomatic, due to using the global list of todo commits: 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:
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.
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 things right, to make clean commits. Imo one of the huge strengths of JJ is abandoning the obsession, and having far far far better tools to clean up after.
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.
It's still a young tool, it's not surprising that tutorials are a bit lacking (honestly there are surprisingly many for its age). Maybe be the change you want to see in the world and make one? (Which would be an... interesting... way to learn the tool for sure).