←back to thread

Jujutsu: A Next Generation Replacement for Git

(www.vincentschmalbach.com)
94 points vincent_s | 5 comments | 08 Jul 24 20:00 UTC | HN request time: 0.001s | source
Show context
donatj ◴[09 Jul 24 11:12 UTC] No.40914710[source]▶
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.

replies(6): >>40914953 #>>40915330 #>>40915843 #>>40916939 #>>40919543 #>>40920358 #
1. ramblerman ◴[09 Jul 24 19:55 UTC] No.40920358[source]▶
> 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.

replies(2): >>40923701 #>>40924873 #
2. s1gsegv ◴[10 Jul 24 04:26 UTC] No.40923701[source]▶
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.
3. thebruce87m ◴[10 Jul 24 08:31 UTC] No.40924873[source]▶
You never fix an unrelated typo or add something useful to the README that you couldn’t find but needed?
replies(2): >>40928822 #>>40930383 #
4. hyperman1 ◴[10 Jul 24 16:49 UTC] No.40928822[source]▶
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.
5. steveklabnik ◴[10 Jul 24 19:17 UTC] No.40930383[source]▶
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.