Jujutsu: A Next Generation Replacement for Git

One of the bigger things I try to hammer in to a junior developers mind is to be conscious and thoughtful about their individual commits. To basically never just "git add ." whatever might just happen to be different in their work area, but to ALWAYS review the diff and make the commit a logical collection of changes.

With the lack of staging area it really seems like this encourages the exact opposite. Seems like a good way to get secrets as well as just general junk and clutter committed to your repo history.

If I am working on a big project, I will start to commit change sets as parts of the code solidify without committing other less solid changes. That seems pretty basic. I don't want half finished changes forever committed to history.

Same here, I am doing a mess between commits, copying and comparing random files, hardcoding secrets for a quick test... To think that it ends up upstream is a thing of nightmares.

I know, gitignore could help, but it eliminates the convenience of being flexible/quick&messy.

This seems like a common misconception. The mention of the staging area in the README points to https://martinvonz.github.io/jj/latest/git-comparison/#the-i.... I'm guessing you didn't click that link. I suppose we need to inline part of the text where we link to it to reduce the number of confused readers.

At this point, I wonder if maybe we should not even mention the staging area. It seems to confuse a lot of people, so maybe it hurts more than it helps to mention it.

Oh, I should also say that we have https://github.com/martinvonz/jj/issues/323 for your concern about automatically tracking files.

I use Jiujitsu, and my personal experience is that the basic "write code, git add what specifically I want to history" flow is the same. The working commit is the effective staging area and it doesn't get forever committed to public history. Without going too much in detail, the working commit can't be pushed to your remote, similar to how the staging area can't be pushed.

There isn't an "explicit" staging area in the sense it's a separate semantic concept that is distinct from a "commit"; rather, the provided machinery for working with commits can be used to do all the things you do with the staging area. The staging area is subsumed as a concept by another concept. By the same token, it also subsumes the stash too. In other words, you can do all the same workflows you do now, but there are fewer "nouns" to juggle. In Git there's the working copy, staging area, and commits. In Jujutsu, there are only commits, and commits are used in more generalized ways with more generalized operations.

To put it another way: the staging area is great because it's really easy to manipulate and "chop it up" as you like. If you make commits themselves really easy to manipulate, just as easy as the staging area, then you can just get rid of the staging area and use commits instead i.e. split a commit in two, or squash two commits together, or parallelize them or reorder them, etc. This actually means that many workflows in Jujutsu are more open ended and flexible than the Git equivalents, while simultaneously having less nouns (which means that, for example, there are fewer UX irregularities because there's less surface area.)

The README that Martin mentions first says there's "no staging area", but then a few paragraphs later mentions that the working copy concept subsumes it and so it provides a superset of functionality. That should probably be rewritten.

Could you explain that just a bit more? I'm trying to figure out how to adapt my personal workflow to jujutsu and this is the part that confuses me.

I think it's me not understanding the difference between "jj new" and "jj commit", but I'm not sure.

I'm a big fan of the staging area for crafting clean commits, so this would be super useful for me to understand.

Your currently active commit is the staging area, only now that it's a "real" commit instead of some bastard half-commit all of your regular tools work with it directly. Same goes with the stash, it's rendered completely irrelevant.

When you're ready to "commit", you give a description to your current set of changes (`jj describe -m`) and then split out any of the pieces you don't want into the next commit (`jj split`). You get to pick the parts you want pulled out, and those get pulled out onto a new, fresh commit.

> I don't want half finished changes forever committed to history.

This is exactly why I hew to squash+rebase. As I like to put it "I don't care about every little sneeze a developer had." Git has spoiled me with this, where I have the power to commit to my private repo anything I damn well please, but in the end I can clean things up and keep the central repo clean and bisectable[0].

Any VCS that doesn't offer these (squash, rebase, bisect) is a complete non-starter for me.

[0] - https://blog.carbonfive.com/always-squash-and-rebase-your-gi...

> To basically never just "git add ." whatever might just happen to be different in their work area

> I will start to commit change sets as parts of the code solidify without committing other less solid changes

I feel like you are pushing your idiosyncratic way of working on others. It's great that you have a way that works for you, but it seems rather odd to me that you would ever be working on more than one thing in the same staging area.

I always git add -a . because I'm working on one specific thing, and my tests just passed.

“jj commit” = “jj describe; jj new”. Basically, jj doesn’t force you to wait until you’re “done” with some work to write the VCS message for it.

The thinking is that you might’ve instrumented other code or de optimized it in a way that you don’t want to commit while solving the problem.

You never fix an unrelated typo or add something useful to the README that you couldn’t find but needed?

Since I started with lazygit, I do it a lot less. The tool makes it extremely easy to select what changed lines belong to which commit. And easy things are done more commonly than hard things.

There's a notion of "empty commits" (commits without messages) in JJ. These are basically the "staging area" of git, and if you try to `jj git push` it JJ will reject. So these commits cannot make it to the remote branch.

To be honest, JJ makes it way easier for me to craft clean commits. The design philosophy of JJ is commit-oriented, not branch-oriented. Since it's a frontend to git, everything it does is fundamentally git. But it allows commit-oriented workflows to flow so much easier than git does.

jj makes this extremely easy by the way. One sample way to do it:

1. jj new (create new change)

2. <make typo fix>

3. jj edit @- (please go back to editing the previous change: @ is the working directory, - means previous. kinda like HEAD^ in git)

You're done in a few seconds, and can get back to your regular work, while that change is split out into its own thing. If you're not as comfortable with the anonymous stuff, you could also `jj new -m 'typo fix'` to set a message then, but for small stuff like this, I don't personally bother until I am done with what I'm actually working on and am ready to submit that too.

If you’re treating @ like the git index (sometimes called the “squash workflow”) then you’d just do the same thing you do in git: squash each part of @ into the proper commit.

Of course, you could also just make it in the current change, and split it out later, but that's easier to forget imho.