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.
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.
> 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.
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.
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).
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).
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".
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.
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.
Some techniques for this are covered in: https://docs.jj-vcs.dev/latest/FAQ/#how-can-i-keep-my-scratc... and https://docs.jj-vcs.dev/latest/FAQ/#how-can-i-avoid-committi...
I’m the same as the parent, auto-track = none() works perfectly for me
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.
> 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.
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.
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.
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).
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).
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".
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.
Yes, I got lost when trying to sync with remote repo from two machines. I'll give it another try.