. * \|/ . o -*- o + o .
o + --*-- * . ' . * . o , . o
. . /|\ + . + . -*- .
. * - o ' . *
- ·:· * . * . * o
2024-12-14
it looks like jujutsu (jj) has been gaining a lot of traction lately. some say that jj provides them with an interface that fits better with how they use git, that it's much more intuitive and easier to use. plus, the backward-compatibility makes it virtually painless to just give it a try.
I've only briefly looked at jj (a few months ago). at the time I had a number of git repos, some of which aren't software-related projects and had high hopes that jj could provide something that makes it easier to work with git.
for me, the most significant difference was the lack of a staging area. in git, when you make a change on a tracked file, the work tree becomes "dirty", changes are only pending. to commit, first put some or all of them in the staging area, then specify the commit message. in jj, all changes are essentially automatically committed to a latest commit (new changes merged like a --amend) until a commit message is specified.
this doesn't quite fit into my workflows. on software projects, I tend to make many changes at once. when it works and I'm ready to commit, I would work with the staging area to split the changes into multiple commits. ie, I would choose just some changes in file A, the entire changed file B, ignore an untracked file C, and commit. then I would stage the remaining changes in file A, start tracking file C, commit again.
further more, I also like to use the staging area in git in order to show new differences in my changes. say I'm implementing a non-trivial feature. when I've tested my current code to be working (but have not yet completed implementing the feature), I would stage all changes in the working tree to mark it as "done". I could then continue editing and testing changes. when something stops working, I could simply "git diff" and it shows the new changes compared to the staging area. to view the changes I have already tested to work (but have for some reason, forgot, or want to review), I could simply "git diff --staged": this shows only the staged changes, and does not include the new changes in the working tree.
it's true that the lack of the need to stage or stash changes in jj makes it easier to move to a different branch, to fixup an older commit or switch context in the middle of doing something else. however, in these situations I would "git commit -am tmp", and do whatever I need to do. when I've come back, I can "git reset HEAD^", or even "git commit --amend --no-edit" to save further changes into a temporary commit.
all in all, there are probably a lot of benefits to jj I haven't yet discovered. however, my initial look at jj was not too convincing for me and some further reading and exploration would be required before I decide whether to move away from git.
do you have a similar workflow as mine, where you make use of the staging area? if you tried jujutsu, what did you think of it and have you decided to switch? I'd love to know.
***
replies:
https://gemini.envs.net/x/freeshell.de/gemlog/2024-12-14_Minor_thing_about_git.gmi
original gemini version
' ` ` ` ' ` ` ` ` ` ` ` ` ` ' ` ` ` ` ' ` ' ` ` ' ` ' ` ` ' ` ``