←back to thread

Jujutsu for everyone

(jj-for-everyone.github.io)
434 points Bogdanp | 3 comments | | HN request time: 0.015s | source
Show context
Ericson2314 ◴[] 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 #
steveklabnik ◴[] No.45088024[source]
1. You wouldn’t use git rere with jj, so that’s sort of a nonsequitor.

2. You treat @ (the working copy) like the staging area, @- (the parent of the working copy) as the commit you’re working on, and then jj squash -i (“interactive”) the parts of the diff you want back into @.

replies(2): >>45088172 #>>45089207 #
Ericson2314 ◴[] No.45088172[source]
If I use JJ in my existing git clone, and then use the occasional git command, I don't want rerere to be messed up
replies(1): >>45088356 #
steveklabnik ◴[] No.45088356{3}[source]
In general you don’t want to mix git mutating commands with jj commands. I believe that there might be a way to get jj to resync its understanding of the word, but I’m not sure what it is off the top of my head.

In rere’s case specifically, I’d expect you’d just be using jj’s rebase, so it shouldn’t be needed though of course want and need are different things.

replies(1): >>45093882 #
1. Ericson2314 ◴[] No.45093882{4}[source]
Mmm I see. Getting out of sync sounds very bad!

https://lore.kernel.org/git/CAESOdVAspxUJKGAA58i0tvks4ZOfoGf... I hope this happens, because then it seems like far less state would be needed on the jj side.

replies(1): >>45097291 #
2. steveklabnik ◴[] No.45097291[source]
It definitely will be nice, but I’m not super heartened by the conversation that ensued.

It also doesn’t super change jj itself, in the sense that it still needs to support other backends, but it does simplify the git backend.

replies(1): >>45103324 #
3. Ericson2314 ◴[] No.45103324[source]
I did not read the whole thread, but I didn't encounter anyone saying "no", just tepid bike-shedding.