The biggest blocker for me to switch to using jj currently is <a href="https://github.com/jj-vcs/jj/issues/3949">https://github.com/jj-vcs/jj/issues/3949</a> which is that it doesn't have a `core.fileMode` option equivalent. What this means in practice is that it's unusable from WSL when your repo is on an NTFS filesystem. It gets confused by NTFS's lack of executable permission bit and makes spurious changes/commits.<p>It's a small thing, but while jj adds some convenience, it doesn't add enough (for me) to offset the inconvenience of changing my workflow to not use WSL. (Another relatively minor inconvenience is its inability to use your SSH configs. So if you have multiple key pairs and need to use specific ones that aren't jj's default pick, an ssh-agent is the only way.)<p>That said, I would 100% recommend jj over git for any new programmer who hasn't yet had to contort their brain already into the git ways. All the things that git's UI does a great job of obscuring and presenting in a confusing way, jj presents in a straightforward way that makes sense and is easy to remember.
Workflow-wise I was struggling a bit to figure out how to work with the bookmarks in jj not moving along.<p>I now have a bit of a new strategy:<p>- When starting up a branch, right up the "final commit message", along with a bunch of notes on what I think I need and other TODOs<p>- While working, when I want to checkpoint some work, I use jj split to chop up some chunk of work, describe it, and then edit up my TODOs<p>this way the tip of my branch is always this WIP commit describing my end goal, I can find it, and I can add a bookmark to it.<p>Instead of git "I add changes over time and make my commit graph move forward", it's "I have a final commit node and add commits _behind it_". Been working well enough.
Thanks for this! Just yesterday I decided to finally start really using jj with real work, whereas I had only fiddled around with it a few times while following tutorials over the past year.<p>One suggestion - reverse the direction of the arrows: q->r rather than q<-r
Is there a short description of how jj works specifically from the perspective of a seasoned git user? I more or less understand git -- how to use it as well as its building blocks -- so the caveats and generalizations and glossing-over that are appropriate for a more general audience seem to get in the way of my understanding what's going on underneath.
I think I'm confused by the box about "jj abandon", which (unlike all the other boxes) talks about "edits" rather than "files" -- which must be a deliberate choice because the legend at the bottom lists "edits" and "files" separately.<p>Shouldn't "edits" be attached to the <i>arrows</i> rather than the <i>nodes</i> in the graphs? So not r [edit3] --> q [edit2] --> p [edit1] but r --[edit3]--> q --[edit2]--> p --[edit1]--> o, where o is p's predecessor. (I think you could do without "edit1" here.)<p>And then "jj abandon q", if I'm understanding it right, turns r --[edit3]--> q --[edit2]--> p into r --[edit3]--> p.<p>(I am not certain I've understood the official docs for "jj abandon" correctly, so it's very possible that I'm wrong about what it does, in which case obviously the above is wrong. But whatever it does, if you're distinguishing "files" from "edits", surely the "edits" go on the edges rather than the nodes of the revision-graph.)
I tried to get into Jujutsu several times and tried to love it, but somehow it seems there is little overlap between the issues I have with git (which there are plenty) and the problems jj tries to solve.<p>My impression is that the main motivation behind jj is that Google realized how difficult and costly it is to train all new hires in their internal tooling but did not want to open-source it completely. So they came up with a thin UI layer, made it workable with git as a backend and published it in the hope it will catch on.
I still don't understand the way jj handles conflicts. If I rebase and then fix a conflict later, are those conflict markers going to appear in some of the commits on github when I push?<p>Maybe I'm in the minority, but I like fixing conflicts as I go. What am I missing?
I've seen several posts on jj, but could anyone please tell what can't be done by git, or what is harder in git but super-easy in jj by providing the sequence of git commands and jj commands for comparison?
So jj calls commits "changes", and this is <i>less</i> confusing? Interesting. I find when you dig into people's understanding of git (or version control in general), a lot of them understand it as storing a sequence of diffs. This small thing breaks their understanding of the whole system. Calling them "changes" seems like it would reinforce this belief. Or is that the idea? Does jj embrace this perhaps more intuitive "sequence of diffs" view, but more successfully hide the "sequence of commits" reality?
Auto-commit of large files and no way to un-bloat your repo is a showstopper for me no matter how good the DX might be.<p>Large file handling needs to be sane in any new VCS, IMHO, as this is a main failing of git (..without the extra legwork of git-lfs).<p>Edit: <a href="https://github.com/jj-vcs/jj/issues/80">https://github.com/jj-vcs/jj/issues/80</a>
Could maybe bring jj up to parity with git here
Does jujutsu have anything like "git am"? I'd like to take a series of patches and jj-ify them so I can play with it. I get that maybe I can't expect to cherry pick a commit because it's naturally different from git. but if I have a patch it seems like I should be able to apply those as jj changes?
Something that I've been struggling to wrap my brain around is:<p>1. Can I use jj inside a repo that was already initialized with git? I think the answer is yes, but I haven't found a tl;dr for it.<p>2. What does the workflow look like to use jj on an existing git repo that all of your coworkers use git for?