A better merge workflow with Jujutsu
1–10 of 93 posts
Re: A better merge workflow with Jujutsu
#2> Using Jujutsu, “amending a commit” also produces a new commit object, as in Git, but the new commit has the same change ID as the original.
This is confusing to me, though to be fair I'm a "git expert" by trade. If you're amending a commit surely the "change" has changed so the change ID should also change? If the "change" isn't tracking the actual changes then what could it be tracking?
Overall I think this is just more confusing than using git but I think it's cool that people are building alternative clients. That's definitely the way to go if you want adoption.
Making history manipulation easier seems like a bit of a recipe for disaster given my experience training people. That old XKCD about git comes to mind and honestly that's where most people stay, if you bother to learn it then things like Jujitsu are probably harder to use for you. If you aren't interested in learning git to that level then I doubt you want / need something like Jujitsu.
For those curious the "multiple branches" at a time thing they're selling can be done with git, IMO easily, using worktrees: https://git-scm.com/docs/git-worktree
Re: A better merge workflow with Jujutsu
#3> Using Jujutsu, “amending a commit” also produces a new commit object, as in Git, but the new commit has the same change ID as the original. This is confusing to me, though to be fair I'm a "git expert" by trade. If you're amending a commit surely the "change" has changed so the change ID should also change? If the "change" isn't tracking the actual changes then what could it be tracking? Overall I think this is jus…
worktrees are pretty great but they make some things a bit more complicated conceptually compared to just checking out two copies for some people
Re: A better merge workflow with Jujutsu
#4[deleted]
Re: A better merge workflow with Jujutsu
#5> Using Jujutsu, “amending a commit” also produces a new commit object, as in Git, but the new commit has the same change ID as the original. This is confusing to me, though to be fair I'm a "git expert" by trade. If you're amending a commit surely the "change" has changed so the change ID should also change? If the "change" isn't tracking the actual changes then what could it be tracking? Overall I think this is jus…
I’ve also run into problems with tools that aren’t worktree aware so often that I’ve stopped using it.
I’ve been using jujutsu for about 6 months now, and the only time I’ve reached back for git was when I had to rebase and amend someone else’s branch to get it merged (when they weren’t available to do so themselves of course).
Switching between changes in jujutsu has been a pleasant experience for me thus far, although I’m not as good with it as I was with stacked-git to keep local only changes (things I’m hacking to match my workflow / local setup) out of change sets.
The way it displays diffs is also still something I am getting used to, and have made plenty of mistakes when pulling in changes from trunk. That’s probably more of a case of “old dog new tricks” than jujutsu.
Re: A better merge workflow with Jujutsu
#6> Using Jujutsu, “amending a commit” also produces a new commit object, as in Git, but the new commit has the same change ID as the original. This is confusing to me, though to be fair I'm a "git expert" by trade. If you're amending a commit surely the "change" has changed so the change ID should also change? If the "change" isn't tracking the actual changes then what could it be tracking? Overall I think this is jus…
> If you're amending a commit surely the "change" has changed so the change ID should also change? If the "change" isn't tracking the actual changes then what could it be tracking?
The author is using newer terminology around "changes", but I prefer the older "revisions", as being less overloaded. But yes, the revision/change ID remains the same even if the commits underneath changes. `jj obslog` will show you the history of commits underlying a revision. This stability is what we want when rebasing, and git doesn't provide it.
> Making history manipulation easier seems like a bit of a recipe for disaster ...
I used to think this too, but it was really due to git and its CLI. Under jj, history manipulation is easy, consistent, and easily reversible with `jj undo`. Because it's safer and easier, I routinely do way more rebasing, and stacked PRs are much less painful to incorporate feedback on. Basically, it makes git's more advanced operations feel like everyday tools.
(Of course, jj doesn't fix the problem of rewriting history that's already been shared with other people, but even there, its notion of immutable commits tries to stop you from breaking other people's histories.)
> the "multiple branches" at a time thing they're selling can be done with git, IMO easily, using worktrees
Worktrees aren't quite the same thing the author is describing. Worktrees allow you to check out multiple branches at the same time to different directories, but they're still sort of separate.
The author is making the working revision a merge revision where every parent is a branch they want to work on. This allows them to see what the code will do when those branches are merged. They can also add revisions to all branches simultaneously by working on the merge rev, and using `jj squash` to choose which parent branch to push work to on the fly. When done for the day, `jj abandon` the merge commit. AFAICT, it's both lighter and more flexible than worktrees.
Re: A better merge workflow with Jujutsu
#7> Using Jujutsu, “amending a commit” also produces a new commit object, as in Git, but the new commit has the same change ID as the original. This is confusing to me, though to be fair I'm a "git expert" by trade. If you're amending a commit surely the "change" has changed so the change ID should also change? If the "change" isn't tracking the actual changes then what could it be tracking? Overall I think this is jus…
Think of the change ID as a "symbolic name", as opposed to the commit ID which identifies a particular snapshot.
As you amend a commit, it creates a new commit ID each time. Only the commit ID of the most recent amendment is in your final graph. All the old ones are orphaned for garbage collection.
The change ID never changes as you make amendments (because you're still working on the same change), and this change ID will always be in the graph. So you can refer to the change ID (which doesn't change) instead of the commit ID (which changes with every amendment).
Another way to think of it would be akin to filenames vs inodes in a filesystem (it's not 100% the same, but the concept should help you visualize). If you delete a file and create another one with the same name, its filename will be the same, but its inode number will be different because it's technically a different file. The old inode gets marked deleted so that it can be reaped somehow. If you make a symbolic link to the file, you'll always get the intended one (because a symbolic link refers to a path). If you make a hard link to the file, you'll get an outdated file after something replaces it (because a hard link refers to an inode).
Re: A better merge workflow with Jujutsu
#8> Using Jujutsu, “amending a commit” also produces a new commit object, as in Git, but the new commit has the same change ID as the original. This is confusing to me, though to be fair I'm a "git expert" by trade. If you're amending a commit surely the "change" has changed so the change ID should also change? If the "change" isn't tracking the actual changes then what could it be tracking? Overall I think this is jus…
I’ve also run into problems with tools that aren’t worktree aware so often that I’ve stopped using it. I’ve been using jujutsu for about 6 months now, and the only time I’ve reached back for git was when I had to rebase and amend someone else’s branch to get it merged (when they weren’t available to do so themselves of course). Switching between changes in jujutsu has been a pleasant experience for me thus far, altho…
Yeah, after the first month of jj, I abandoned git forever, because it's already so much better. There are some hiccups, though.
I switched over to colocation for all repos, because too many things expect git directories to be where they expect.
I think the revset language is cool and powerful, but if I'm honest, it's tempting me to spend too much time trying to master, when 99% of the time all I need is, "show me the nearby ancestors and descendants within k revisions".
I think the diffs need work. Or I need to get comfy with 3-way diffs. It's unfamiliar, and an obstacle to fixing conflicts. Luckily I get maybe 1/10th the conflicts I used to under git.
Re: A better merge workflow with Jujutsu
#9I really like the idea of Jujutsu and was really keen to try it out but when I looked at it several months back I found it really hard to get going with it and ended up just ditching it. This article looks to be a explanation to some of the concepts of `jj` and how to use it in a little more depth than some of the other tutorials I have seen out there. Definitely keen to give it another try at some point
Re: A better merge workflow with Jujutsu
#10Earlier quoted context omitted.
I’ve also run into problems with tools that aren’t worktree aware so often that I’ve stopped using it. I’ve been using jujutsu for about 6 months now, and the only time I’ve reached back for git was when I had to rebase and amend someone else’s branch to get it merged (when they weren’t available to do so themselves of course). Switching between changes in jujutsu has been a pleasant experience for me thus far, altho…
Yeah, after the first month of jj, I abandoned git forever, because it's already so much better. There are some hiccups, though. I switched over to colocation for all repos, because too many things expect git directories to be where they expect. I think the revset language is cool and powerful, but if I'm honest, it's tempting me to spend too much time trying to master, when 99% of the time all I need is, "show me th…
> I think the revset language is cool and powerful, but if I'm honest, it's tempting me to spend too much time trying to master, when 99% of the time all I need is, "show me the nearby ancestors and descendants within k revisions".
I just spend enough time to write a new function for what I want to do, and then just know the basics for regular day to day stuff. I feel like that gets me really far.