←back to thread

Jujutsu for everyone

(jj-for-everyone.github.io)
434 points Bogdanp | 4 comments | 31 Aug 25 15:31 UTC | HN request time: 0.001s | source
Show context
Ericson2314 ◴[31 Aug 25 17:11 UTC] No.45084874[source]▶
I want to read "Jutustsu for Git experts"

For example, will the committing of conflicts (a good idea I agree), mess up my existing git rerere?

Also I agree that the staged vs unstaged distinction is stupid and should be abolished, but I do like intentionally staging "the parts of the patch I like" while I work with git add -p. Is there a a lightweight way to have such a 2-patch-deep patch set with JJ that won't involve touching timestamps unnecessarily, causing extra rebuilds with stupid build systems?

replies(3): >>45085487 #>>45088024 #>>45088309 #
1. sfink ◴[01 Sep 25 00:23 UTC] No.45088309[source]▶
Yes, and this is the most commonly used workflow these days with jj (the "squash workflow"). You have a top commit, which is also your working directory, and you make changes freely. To "stage" something, you squash it down into the next commit (all changes, or interactively selected changes with -i aka --interactive).

This generalizes to using a whole stack of "stages", by doing ´squash --into´ to select the patch to put the changes into if it's not just the next one down.

replies(1): >>45103341 #
2. Ericson2314 ◴[02 Sep 25 14:09 UTC] No.45103341[source]▶
Ah a squashing of the top commit in a git rebase will touch the working tree more than necessary. But jj might just not do that?
replies(1): >>45107119 #
3. sfink ◴[02 Sep 25 18:29 UTC] No.45107119[source]▶
Oh, I missed this part. I think jj is better here in at least one scenario.

Specifically, I believe the scenario you're talking about is:

    change file1
    build, producing binary.out
    squash the change down (leaving your working copy unmodified)
    rebuild
If the squash updates the timestamp on file1, then the rebuild will redo the compilation steps that use file1 as input.

When I test it out, it looks like doing a whole-file squash with jj does not update the timestamp. Hm... I guess even a partial squash doesn't update the current contents, let me try that too... yes, again jj does not touch the file nor update its timestamp.

So it looks like it does do what you want, if I'm understanding things correctly.

replies(1): >>45127380 #
4. Ericson2314 ◴[04 Sep 25 14:00 UTC] No.45127380{3}[source]▶
Yeah that makes sense!l. With git reset HEAD^ --soft, git commit --amend, git will do the same thing, but it won't bother to do that with rebases.