31–40 of 52 posts
How do the rebased commits work when working with others together on a branch?
It's no different from how rebasing works in any shared git project; rebased commits are re-created with different SHAs.
Earlier quoted context omitted.
You can edit your commit message ahead of time in git too.
What's your workflow like to do this?
You then add your changes and "git commit --amend".
(These could be aliases. Mine are "ci" and "ca" respectively.)
I’m quite happy with Sapling at work. I still haven’t figured out what Jujutsu does better. I think nothing substantial? Not that Sapling can be easily used in the public sphere. But at a conceptual level I’m not sure there’s anything in JJ I’m missing.
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…
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”.
Earlier quoted context omitted.
What's your workflow like to do this?
There's nothing to it, it's just "git commit". You then add your changes and "git commit --amend". (These could be aliases. Mine are "ci" and "ca" respectively.)
Earlier quoted context omitted.
It's no different from how rebasing works in any shared git project; rebased commits are re-created with different SHAs.
Right but that doesn't address the collaboration issue: who gets to decide where the branch points to?
jj force pushes by default, but unlike git, the force push defaults to the "safe" variant (similar to git's --force-with-lease). So you won't accidently overwrite someone else's changes with your force push.
Earlier quoted context omitted.
There's nothing to it, it's just "git commit". You then add your changes and "git commit --amend". (These could be aliases. Mine are "ci" and "ca" respectively.)
You can do that. But I mean there is literally a spot in the .git directory for the work-in-progress commit message. When you later do git commit -a or whatever, it pulls up the message.
Great article. How do people deal with the lack of branches, esp in a full time setting where it's common to have a few independent features on the go?
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 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.
Someone has made a VSCode plugin but it's closed source and I believe it will be paid at some point? https://www.visualjj.com/
If you are willing to use a TUI, jj-fzf (https://github.com/tim-janik/jj-fzf) has been wonderful and development is extremely active too.
I exclusively use git through the GUI, but the jj CLI improves so much over the git CLI that I'm willing to live with the CLI for now.
Still hoping that the GUIs become more polished though, and also for Inteliij IDEA integration.