This is the first summary of Jujutsu that has made me truly want to give it a try. I had it on my radar as something to check out but never felt motivated to because it seemed like I was going to have to put a lot of effort into changing my workflow from the one with the default Git porcelain. Based on this post, it sounds very logical and I'm looking forward to trying it on a project at work.
The Jujutsu version control system
41–50 of 52 posts
Re: The Jujutsu version control system
#42Earlier quoted context omitted.
Sapling is great. I worked on it for many years at Facebook and I think we did a pretty good job building a workflow that most developers preferred to Git. To the extent that Jujutsu is similar to any other systems, it is most similar to Sapling — both have a Mercurial heritage (Sapling is derived from hg, while Jujutsu is a new codebase with an hg-inspired UX). However, Jujutsu introduces a number of fantastic impro…
> automatic working copy snapshots One of my favorite things about Sapling is that all commits are automagically backed up to the cloud. The D in DVCS is not important for roughly every project ever. So I’m not sure how to feel about “every state is a commit”.
I'm not sure why you think the two are incompatible? Commit Cloud is pretty great but makes more sense in a corporate environment. You don't have to upload every automatic commit that gets made locally, though you could choose to if the capacity requirements work out.
The automatic snapshots provide a great degree of UX coherence — definitely more than Sapling currently does. (When I last chatted with the Sapling folks, they were quite interested in porting some Jujutsu features over to it.)
Re: The Jujutsu version control system
#43Earlier quoted context omitted.
> automatic working copy snapshots One of my favorite things about Sapling is that all commits are automagically backed up to the cloud. The D in DVCS is not important for roughly every project ever. So I’m not sure how to feel about “every state is a commit”.
I'm not sure why you think the two are incompatible? Commit Cloud is pretty great but makes more sense in a corporate environment. You don't have to upload every automatic commit that gets made locally, though you could choose to if the capacity requirements work out. The automatic snapshots provide a great degree of UX coherence — definitely more than Sapling currently does. (When I last chatted with the Sapling fol…
Uploading everything everytime someone runs jj status seems potentially burdensome. Uploading on every commit is maybe also burdensome but at least it’s also nice and explicit? I dunno maybe it’s fine! Or maybe some heuristic would make it fine enough. I don’t really get the “working copy commit” concept. It hasn’t clicked yet.
> The automatic snapshots provide a great degree of UX coherence — definitely more than Sapling currently does.
Don’t think I understand what this means.
Re: The Jujutsu version control system
#44Earlier quoted context omitted.
You can edit your commit message ahead of time in git too.
What's your workflow like to do this?
Initial empty commit with just a message you can create with "git commit --allow-empty -m'Early commit message"
Then when you have the changes lined up you --amend that same commit.
Re: The Jujutsu version control system
#45Earlier quoted context omitted.
There are still branches, but they aren't named by default. You give them names with "bookmarks", which you can push to remote git repositories as branches. This lets you work on things without having to worry about giving it a name. This turns out to be pretty helpful when you're experimenting — just "jj new " and start editing. If it turns out to be something you want to share, "jj bookmark create " and then you ca…
What changes the change ID? What constitutes a change? Is a change made up of many commits, or the other way around?
A change ID is stable over time as you tweak the message of the change or the files edited by the change. Each of these changes become a new immutable git commit under the hood.
The fact that change ID is stable is very convenient for humans - means you have something explicit to hold on to as everything else may change over time.
Re: The Jujutsu version control system
#46Earlier quoted context omitted.
I'm not sure why you think the two are incompatible? Commit Cloud is pretty great but makes more sense in a corporate environment. You don't have to upload every automatic commit that gets made locally, though you could choose to if the capacity requirements work out. The automatic snapshots provide a great degree of UX coherence — definitely more than Sapling currently does. (When I last chatted with the Sapling fol…
Uploading everything everytime someone runs jj status seems potentially burdensome. Uploading on every commit is maybe also burdensome but at least it’s also nice and explicit? I dunno maybe it’s fine! Or maybe some heuristic would make it fine enough. I don’t really get the “working copy commit” concept. It hasn’t clicked yet. > The automatic snapshots provide a great degree of UX coherence — definitely more than Sa…
Try jj out on an open source Git repo -- I think it will both be very easy to pick up, since you're used to Sapling, and quickly make sense.
You know how sl amend and sl fold/squash are two different commands, right? Well, jj amend is actually an alias for jj squash. And that's just the beginning.
Regarding uploading, yeah, you'll likely have to have some heuristics, but Mononoke is generally built for very high throughput. The heuristics might just be around local debouncing and aggressive expiry of uncommitted snapshots in the cloud. But in general, it's worth thinking about the local moment-to-moment UX independently of commit cloud considerations.
Re: The Jujutsu version control system
#47Earlier quoted context omitted.
There are still branches, but they aren't named by default. You give them names with "bookmarks", which you can push to remote git repositories as branches. This lets you work on things without having to worry about giving it a name. This turns out to be pretty helpful when you're experimenting — just "jj new " and start editing. If it turns out to be something you want to share, "jj bookmark create " and then you ca…
Adding onto this, there’s also an experimental feature to move a bookmark as you create new revisions (similar to how a git branch behaves)
Oh, that would be nice. I get the reasoning not to, but it would be nice to have the option.
Re: The Jujutsu version control system
#48I use jj for all my projects on github! It's really useful for my sort of workflow: chains of commits with easily-editable history. If you make a change back in time, you edit the previous commit (which puts you in a state similar to git's detached head), and any edits you make there are automatically carried forward (rebased) onto descendants. It feels way more natural, especially for newer users. The killer feature…
> It feels way more natural, especially for newer users. I have thought about this recently, and it feels like jj would be a lot easier to teach to new users than git. For one, jj lets you work on things directly without having to worry about an index, while still giving you all the advantages of one if you're advanced enough to need that. THe commands also feel a lot easier to explain than in git. For example, you u…
I feel like one of the reasons I see the problems with git more than many commenters on here is precisely because I often teach beginners who do not have a CS background.
Re: The Jujutsu version control system
#49What front ends work with jujutsu? Do I have to start doing all on the command line, or can I use existing clients such as Fork? Kudos for the article. I have been seeing jj here and there, but this is the first that made me want to try it.
I've been itching to use jj for real but the lack of a dedicated Neovim plugin killed my enthusiasm a bit.
Yes, regular git plugins sort-of mostly works, but it's different enough to introduce a lot of painful edges when you do.
Re: The Jujutsu version control system
#50I use jj for all my projects on github! It's really useful for my sort of workflow: chains of commits with easily-editable history. If you make a change back in time, you edit the previous commit (which puts you in a state similar to git's detached head), and any edits you make there are automatically carried forward (rebased) onto descendants. It feels way more natural, especially for newer users. The killer feature…
Sounds kind of like perforce
jj was inspired by a bunch of internal Google tooling around their VCS, which was originally built on top of Perforce, so I'm not surprised the history shows through a little.