2 ms·
> In other words, I actually understand git, so I don't really need Jujutsu. This is kind of a poor take. By all means use what you prefer! But understanding g
by stouset 1y ago
> In other words, I actually understand git, so I don't really need Jujutsu.
This is kind of a poor take. By all means use what you prefer! But understanding git and knowing the "right" way to use it doesn't make jj obsolete.
I am (or was) a git expert. I’ve used it since pre-GitHub. I’ve written a git implementation. I know (or knew) the interface inside and out. I haven’t deleted and re-cloned a repo in as long as I can remember.
jj is still leagues better. Things I want to do and know how to do in git are dramatically faster and easier. They require less mental overhead. They’re less error prone. And I get superpowers with workflows that are super useful but wildly impractical in git.
This isn’t even really opinion at this point. Any task you can give me in git, I can with almost near certainty give you a shorter and more elegant alternative with jj that is an intuitive and obvious interaction with its core primitives.
A month ago our company split off a division. They needed to take a specific repo and sanitize out all of the parts that aren’t relevant to the new company, going back to the beginning of its commit history. You can do this with git. It wouldn’t be fun. I’d have to spend a lot of time reading the filter-branch manpage, and people have written countless wrappers of varying quality that try and make it a bit more ergonomic.
It took me like ten minutes to come up with:
declare -rA paths=(
…
)
# for every commit that touched a file
# we want to excise
for id in "$(
jj log \
--revisions '..' \
--no-graph \
--template 'change_id ++ "\n"' \
"${paths[@]}"
)"; do
# restore those paths’ contents from the
# the empty root commit; this happens
# entirely in-memory without having to check
# out each revision into the working copy to
# do file operations so it is FAST
jj restore \
--from 'root()' \
--to "${id}" \
"${paths[@]}"
done
# remove any commits that are now empty
# (except for the implicit root commit)
jj abandon \
--revisions 'empty() ~ root()'
Three dumb, simple commands that I already use every day: list some commits, copy file contents from one commit into another, and remove some commits from the tree.
Not only was this more or less obvious to do, but it was exceedingly fast to perform on a pretty highly-trafficked repo due to not having to thrash around in the working directory with checkouts.
> Magit is a much better git frontend than Jujutsu. It guides you down the right path but doesn't take away any of the power of git at all.
jj is more powerful than git. It’s not simply a dumbed-down alternative. By having a more carefully chosen set of primitives that compose better, you gain a lot of abilities that are technically possible with git but never used in practice due to the complexity. The above is IMO a fantastic example of how and why.
And you can still do all the normal git things too.
- latexr 1y ago> This is kind of a poor take. Why? They’re sharing what they prefer in response to someone claiming that everyone who tries the other thing comes to prefer that. They’re offering a reply in context and not in the slightest saying everyone should follow what they do. > By all means use what you prefer! That’s exactly what they’re doing. > But understanding git and knowing the "right" way to use it doesn't make jj obsolete. Which they haven’t claimed at all. You seem to be objecting to an argument which hasn’t been made.
- ben0x539 1y ago"In other words, I actually understand git, so I don't really need Jujutsu." sounds like jj is for people who don't understand git. That's naturally a contentious statement. It implies that jj doesn't offer anything to experts, which seems easy to contradict given how many people with git expertise will talk about getting value from jj. At worst, it could be taken as a bad faith kinda put-down, like, suggesting at jj users are worse at their job than people who make do with git. I think it's totally fair to take push back against how that was worded.
- latexr 1y agoAlright, that’s fair, I can indeed see that reading.
- globular-toast 1y agoThanks for the thoughtful reply. I can see how in fact jj could be considered an adjacent tool to Magit. Similarly Magit does not "dumb down" git like other git GUIs. As the Magit manual puts it, it's actually a fully fledged git porcelain. I guess jj is the same. So I think I would revise my comment above and say I don't need jj because I've already got a toolkit that does a similar thing. I haven't raw dogged the git CLI in a decade. However if I ever run into a problem like yours and my tools aren't cutting it I'll definitely keep jj in mind so thanks for showing me!