481–490 of 517 posts
Earlier quoted context omitted.
then create one when you are done adding?
why bother? jj does it automatically and gives tools to work with such commits, no point to force this on yourself with git
A lot of the discussion focuses on differences from git and how it uses the git storage strategy under the hood. Honestly, I think you should just ignore all of that. Don't think about git. Here's a workflow that'll get you through your daily usage: On a clean repo: $ jj The working copy has no changes. Working copy (@) : abcdef a53ff9ba (empty) (no description set) Parent commit (@-): qrstuv 4bc1bf34 the last thing…
> Don't think about git. You can also make the reverse point, only think about git: In theory it's perfectly possible if you have to jj binary lying around somewhere, to not even use it as your git client, but to temporarily do a `jj git init --colocate`, do a complex restructuring of your repo across 3 branches, and then delete the .jj folder again :-) Just to highlight the other end of the spectrum, jj is flexible…
Earlier quoted context omitted.
I did try it, but it was not my cup of tee. Git fits my mental modal better. Branches are experiments, commits are notes in my lab notebook, stashes are notes in scrap of papers, the staging area is for things that I plan to note down and the working tree is the workbench. Then every once in a while I take the notebook and rewrite stuff in it or update it to fit recent changes in the canonical branches. I use magit s…
The problem jj is trying to solve is not entirely clear to me but I guess there is enough people who aren't able to find their way with git so for them it probably makes switching to jj more appealing, or at least that's my first impression without going too deep into the documentation.
Earlier quoted context omitted.
I wouldn't say it's that people are not able to find their way with Git. I was a competent Git user and would carefully and squash my commits. It's just easier and nicer with Jujutsu. The way all changes (except those in the ignore file) are automatically incorporated into the current commit means I don't have to faff about with stash when I need to pivot and then try to remember which commit to pop against. I can ju…
> Then add in the fact that a change to history gets rippled down the descendent commits. This sounds interesting. Could you go into a bit more detail? I have 3 branches off of a single commit, update that commit, and all branches automatically rebase? Or?
So yeah if I have revision `a` with two children `b` and `c`, and even if those children have their own children, a change to `a` will get rippled down to `b` and `c` and any further children. It's a bit like Git rerere if you've used it, except you're not forced to fix every conflict immediately.
Any conflicts along the way are marked on those revisions, you just fix the earliest conflicts first and quite often that'll ripple down and fix everything up. Or maybe there'll be a second conflict later down the stack of commits and you'll just fix that one the same way.
To fix a conflict you typically create a new revision off the conflict (effectively forking the tree at that point) using `jj new c` (let's call the result `cxy`) fix the revision in that commit and then you can `jj squash` that revision `cxy` back into `c`. This, again, gets rippled down fixing up all of the descendent commits.
One of my favorite jj features is "jj absorb". For each change you've made in the current revision, it finds the last commit where you made a change near there, and moves your changes to that commit. Really handy when you forgot to make a change to some config file or .gitignore. You just "jj new", make the changes, and "jj absorb". No need to make a new commit or figure out where to rebase to. Oh, and not having to…
After hearing about a workflow that used absorb I wrote a simple git version I called 'squash-index' in about 15 lines of bash in a few minutes. Since git allows subcommand extension I just made an executable 'git-squash-index' and everything worked as if it was a builtin subcommand. I get that initial ergonomics are important for new tools but if the only novel feature is reified merge conflicts it doesn't really se…
With jj, it's the same as any other commit. No new commands, no new options.
Earlier quoted context omitted.
I'm about the same. jj is kind of perfect for that. Example: # I've finished something significant! Carve it out from the working "change" as its own commit. `jj commit --interactive` # aka `jj commit -i` or `jj split`, depending on how you prefer to think of it: making a commit for some work, or splitting a separate commit out of the working change. # Oops, missed a piece. `jj squash --interactive` # aka `jj squash…
# I've finished something significant! Carve it out from the working "change" as its own commit. git add -p git commit # Oops, missed a piece. git add -p git commit --amend # Let me look at what's left. git diff # Oh right, I had started working on something else. I could just leave it in the working change, but let me separate it out into its own commit even though it's unfinished, since I can always add pieces to i…
If I'm writing a description of how to use jj, I could take several different approaches. Am I writing for a git novice? A git expert? An expert in a different VCS? A novice in any VCS? And even within those, there's a big difference in whether you're a solo dev working alone on their own project, a solo dev working across multiple systems, a random github contributor working alone against a github repo, a group of contributors who work together before landing something in an upstream repo, or whatever. And then, it matters whether my objective is to show that jj is somehow superior, or to just show to accomplish something.
Those are going to require rather different approaches. I was not going for "jj is better than git". I was aiming more for "here's how straightforward it is to do the sort of stuff you're talking about". Even with the example actions I described, jj does have a couple of advantages that I didn't highlight: first, your git equivalents would require looking up commit hashes whereas in jj I tend to remember the recent change ids that I've been working with. Second, `jj undo` (and its stronger variant, `jj op restore`) is easier and simpler to work with than the reflog. A longer example would have demonstrated that, but I didn't want a longer example.
But I have no dispute with your assertion that this workflow is not harder in git. I could write a description of why I think jj is better than git, it's just that my post was not that. (I could also write a post about how jj is still missing some important functionality that git has, and therefore git is better than jj.)
But just to sketch out what I would use if I wanted to make git look bad, I'd probably use an example of multiple independent lines of development where I want to work off of a tree with all of them applied at the same time, without artificially linearizing them because I don't know what order reviews are going to come in, and then doing fixups and incorporating new changes that turn out to conflict, and not getting stuck working through conflicts in the other patch series when I'm actively working out the finishing touches on one of them that turns out to be high priority. And then getting some of that wrong and wanting to back up and try a different path. All while carrying along some temporary logging or debugging changes, and perhaps some configuration changes that I don't ever want pushed. And keeping my patch series clean by separating out refactoring from changes, even when I actually do bits of that refactoring or those changes out of order. And doing all this without risking modifying anything other people might be using or building off of, by preventing force pushes on stuff that matters without preventing it for in-development stuff that is only relevant to me. And in the middle of this, wanting to look back on what the state of things was last Wednesday, including the whole commit graph.
All of that is possible with both git and jujutsu. In practice, I wouldn't even try much of it with git. Perhaps I just suck at git? Very possible. I'm better with mercurial, but I wouldn't do a lot of that there either. I won't say all of that is trivial with jj, but some of it is easy, all of it is doable without thinking too hard, it's the sort of stuff that arises for me quite often as I'm working, and none of it requires more than the same handful of commands and concepts. I know what changes are tentative and what are more fixed without juggling commits vs staging vs stash, and I can freely move bits and pieces between them using the same set of commands. I could do the exact same things in git, but I wouldn't. The core git data model is very nice, so it's pretty clear what can and can't be done. jj gives me the ability to manipulate it without tangling my head or my repo in knots.
Earlier quoted context omitted.
I wouldn't say it's that people are not able to find their way with Git. I was a competent Git user and would carefully and squash my commits. It's just easier and nicer with Jujutsu. The way all changes (except those in the ignore file) are automatically incorporated into the current commit means I don't have to faff about with stash when I need to pivot and then try to remember which commit to pop against. I can ju…
There must be some kind of split in how people work or something. I’ve never had the desire to jump around the git tree. I never squash commits. I basically never stash changes. All the things that people say jj makes easier are things I never even want to do. Not because they’re not easy with git, but because it sounds hard to keep straight in my head.
But I frequently have cases where I have some changes I'm making to repo `acme`. I'll put a PR up for review and then I'll start on a second PR for the same repo. I stack these commits on top of my previous PR. If I then notice a problem in the earlier work I can easily fix it and have the changes ripple down to the later PR. Or if somebody else merges something in against `main` it's really easy using `jj rebase` to move my commits against the new version of `main`. With a single `jj rebase` I can move all of my stacked PRs over to the new version of `main` and have every stacked PR updated.
Earlier quoted context omitted.
My command looks like either: fragmede@laptop:(abranch)~/projects/project-foo$ or fragmede@laptop:(abcdef)~/projects/project-foo$ Depending on if abranch is checked out, or abcdef which may be HEAD of abranch is checked out. If you're having to run `git status` by hand to figure out which of the two states you're in, something's gone wrong. (That something being your PS1 config.) If people are having trouble with tha…
The only thing that changed in the two things you wrote was `ranch` -> `cdef`. Every other part of that PS1 output was the same. Now put yourself in the shoes of a git novice and ask yourself if you'd always notice the difference. At least from my experience, they often don't, especially if they're concentrating on something else, it if they're using an IDE and the visual information about which branch/commit is chec…
fragmede@laptop:(main)~/projects/project-foo$
fragmede@laptop:(cf95b5ac22fd...)~/projects/project-foo$
fragmede@laptop:(opengl_meters)~/projects/project-foo$
I don't know how much it matters in AI-codepocalypse because I'll be honest, I haven't used git manually in days. AI writes my commit messages and deals with that shit now. (Claude ends a session with "Want me to push it?" and I just reply "yes".
> Similarly, I think to you, unnamed branches feel like something complicated because in git they are.
It's not that working with unnamed branches in git seems complicated, it's that it seems opposite to how I, and by extension, other people work. Now, obviously that assumption of mine doesn't hold true, otherwise we wouldn't be having this discussion, but going back to my Google docs example, staring at a page of documents called Untitled document isn't helpful, so in my mind, there's just a bit of digital hygiene that's necessary under any system.
> I really recommend having a look at the output of `jj log`, because I think then it'll be a lot clearer what I mean when I say that it's not hard to figure out what the right commit is.
You tell me which commit I want from this `jj log` output:
@ nlvqqyzv fragmede@example.com 2026-04-15 04:43:07 0d644b5d
│ (empty) (no description set)
│ ○ nkuswmkt fragmede@example.com 2026-04-15 04:43:07 e071e1a5
├─╯ (no description set)
○ ytyvtmpr fragmede@example.com 2026-04-15 04:42:51 bd5b4717
│ (no description set)
│ ○ srmtuszo fragmede@example.com 2026-04-15 04:42:35 aa64aea2
├─╯ (no description set)
○ nrqwxvzl fragmede@example.com 2026-04-15 04:40:42 c1dbbda3
│ (no description set)
Again, I'm not trying to die on a "git is easy to use" hill, because it isn't. My point was that "> these two states look completely identical" isn't true if you setup PS1 to tell you what state you're in.
jj gets a lot of things right, there's no panicking that work got lost. That is a big deal! The emotion toll that the possibility of that happening with git causes on new users is hard to understate. It's hard to not be scared of git after you've lost hours of work after running the wrong command.
I didn't raise $17m to build what comes after git, although I've thought a lot about that problem. Improvements in that area are welcome, and the easier it is for people to work with stacked change sets and branches, globally, can only be a good thing. I can't make everyone else get as good at git as I am (or better!), so I welcome better tooling.
Earlier quoted context omitted.
The problem jj is trying to solve is not entirely clear to me but I guess there is enough people who aren't able to find their way with git so for them it probably makes switching to jj more appealing, or at least that's my first impression without going too deep into the documentation.
Some of jj's users are "I find git hard and like jj more" but a lot of us are/were git experts before switching.
Earlier quoted context omitted.
why bother? jj does it automatically and gives tools to work with such commits, no point to force this on yourself with git
sure, but i don't think it's that big of a deal either way. it's not the specific feature that draws me in. the overall concept of saving everything as a commit is interesting however. not needing to manually commit after adding changes is just a small positive side effect.