Earlier quoted context omitted.
nice to see zellij+helix combo users out there. Helix been my fav editor for like a year already, zellij is also a daily driver, and now i'm learning jj :P
Do you use nixos? ;)
nah I'm on wsl
Steve's Jujutsu Tutorial
101–110 of 120 posts
Re: Steve's Jujutsu Tutorial
#102Earlier quoted context omitted.
For me, my git brain is very low level. And none of them ever explains what actually happens under the hood, or how that was different than branching… With some respect, I think “rebase centric workflow” doesn’t really cover it: I use rebasing heavily with GitHub. A “trunk based development where all branches are rebased before merge so there’s never merge commits, please add to commits and rebase the branches in res…
What I find confusing with people raving about it as something different is the considering the following scenario: refactor/a # should be merged as independent PR feature/a-b # depends on a; should be merged independently, after fix/c # independent Then I will probably have some local `dev` branch checked out with a combination of all of the above and maybe some. How else than "stacked diffs" would you submit all of…
GH did not really support automated base change (after merging) not that long ago, so doing this as stacked diffs/prs there was quite annoying. I guess that's why people tried to avoid it for a long time? I know I did some weird PRs in the past just to keep them independent. It could still be improved today (why is main the base when the branch contains an existing PR? adjust it automatically, please!), but it's not a big issue anymore.
Re: Steve's Jujutsu Tutorial
#103This was informative, thanks Steve! The only problem I had was that the difference between changes and commits wasn't clarified enough in the beginning, and I got lost trying to distinguish between the two. I'm on chapter 4 and I'm still not sure what a change is and what a commit is. From a tiny bit of previous jj experience, my mental model is "a commit is the snapshot, and a change is what happened between snapsho…
Thanks for the feedback! I think these terms are used a bit loosely, even though I try to be precise about it. Your mental model sounds decent. I think there’s a few ways to describe things. I like to think of changes as a stable ID for something I want to accomplish, and a commit as the intermediate steps that make up a change. You can kind of think of a change as a branch… but I think that’s stretching it.
OK, going through the tutorial again, I think the difference between commits and changes are definitely the thing to focus on. Before your comments, I felt like I was building on a small foundation, because I didn't understand how commits and changes relate, and didn't have a good mental model of them.
After your comments, the entire tutorial is more solid, but still I feel like I have gaps. My feedback would be to really focus on commits vs changes and define their relationships, what affects them, etc before you go into anything else.
Re: Steve's Jujutsu Tutorial
#104Earlier quoted context omitted.
For me, my git brain is very low level. And none of them ever explains what actually happens under the hood, or how that was different than branching… With some respect, I think “rebase centric workflow” doesn’t really cover it: I use rebasing heavily with GitHub. A “trunk based development where all branches are rebased before merge so there’s never merge commits, please add to commits and rebase the branches in res…
What I find confusing with people raving about it as something different is the considering the following scenario: refactor/a # should be merged as independent PR feature/a-b # depends on a; should be merged independently, after fix/c # independent Then I will probably have some local `dev` branch checked out with a combination of all of the above and maybe some. How else than "stacked diffs" would you submit all of…
A crutch, I think. Or a crotch; I don't judge.
Re: Steve's Jujutsu Tutorial
#105Earlier quoted context omitted.
The holy grail of a stacked diff workflow would be making multiple Github PRs each made against the previous branch instead of trunk, and then updating the branch that's closest to trunk and rebasing all of the children PRs without having to force push into any of them. Git and Github do not support this workflow directly, and this creates space for all the other tools. Jujutsu comes close to supporting this workflow…
The https://github.com/sunshowers/spr fork supports jj :)
Beautiful, thank you!
Re: Steve's Jujutsu Tutorial
#106I am torn between sapling and jj. Both make good progress in git/github integration which seems to have been the major road block in adoption before. One other major roadblock seems to be the limits of review tools supporting stacks: github PRs are too limited, gerrits ux is horrible, graphite does not work and is not open enough, saplings review tool is just a very slow performing POC (though with a really good UI c…
Could you say more about how/why "graphite does not work"?
Re: Steve's Jujutsu Tutorial
#107Been using jj at work for months now. In colocated mode, JetBrains IDEs even retain some if their VCS integration. The ability to easily work on top of an octopus merge and then push changes "down" into the contributing branches has been a live saver when my team had to do a big refactoring in a mono repo and split the changes into small PRs for individual teams (code owners). The auto committing behavior is a bit we…
100% agreement on that transition. I feel like I had to unlearn a lot of git’s subtly-broken model and now things feel so much simpler and easier.
One of those for me was branch names that don’t automatically “follow” new commits. At first it felt weird but it unlocks the ability to do consecutive work as one linear set of changes, even when those changes need to be merged in discrete chunks. The git approach for this (stacking branches) is so painful, particularly when you need to edit an earlier change or add a new commit between earlier ones. This went from being so frustratingly difficult I wouldn’t even consider it to being utterly trivial.
Also rebase conflicts. Not being unceremoniously dropped into a half-broken “fix this NOW state” with no ability to inspect and poke at other commits in the chain and not being able to fix things incrementally in any order is something I couldn’t have imagined. And like you said now it’s insane to me that people continue to put up with it.
Re: Steve's Jujutsu Tutorial
#108Earlier quoted context omitted.
> The auto committing behavior is a bit weird at first I am a bit skeptical about this, because this requires a jj daemon?
It's a bit of a magic trick. A "snapshot" is taken any time a command is run, and it happens implicitly before any actual algorithms or code for a given command is run (massively simplifying the internal design), so for all intents and purposes it's "automatic" from the user interface e.g. even checking repo status or otherwise small operations will cause a snapshot. But you can integrate with https://github.com/face…
What’s also amazing is this means you’re no longer completely on your own when fixing things up.
I can’t tell you how many times I got midway through a git rebase, realize I’d fucked up earlier, and had to abort and redo everything from scratch. With jj not only is this not a problem (thanks to conflict markers being first class citizens) but also any intermediate changes are being snapshotted without me having to do anything. So I can always go back to an earlier change if need be.
The first time I had to do this I’d royally fucked up a complicated commit reordering sequence while screen sharing during a meeting. I’d never needed to use the op log before and had no idea how to use it. It took maybe a minute or two to fix things completely.
Re: Steve's Jujutsu Tutorial
#109Been using jj at work for months now. In colocated mode, JetBrains IDEs even retain some if their VCS integration. The ability to easily work on top of an octopus merge and then push changes "down" into the contributing branches has been a live saver when my team had to do a big refactoring in a mono repo and split the changes into small PRs for individual teams (code owners). The auto committing behavior is a bit we…
Full agreement on both “it feels weird” -> “how do people ever tolerate the old way” as well as the auto commit behavior being one of those things. In fact I probably over-index on that specifically when talking about jj. I thought I’d hate this because I love git’s index. Turns out that by getting rid of the index, jj has a better index than git does, but that sounds insane at first!
Same about the index! I initially skipped over jj thinking the lack of an index was a huge step backwards but commit-splitting is a massive improvement.
I do wish there was a better front end for it though.
Re: Steve's Jujutsu Tutorial
#110Earlier quoted context omitted.
What I find confusing with people raving about it as something different is the considering the following scenario: refactor/a # should be merged as independent PR feature/a-b # depends on a; should be merged independently, after fix/c # independent Then I will probably have some local `dev` branch checked out with a combination of all of the above and maybe some. How else than "stacked diffs" would you submit all of…
GH did not really support automated base change (after merging) not that long ago, so doing this as stacked diffs/prs there was quite annoying. I guess that's why people tried to avoid it for a long time? I know I did some weird PRs in the past just to keep them independent. It could still be improved today (why is main the base when the branch contains an existing PR? adjust it automatically, please!), but it's not…
Also this workflow is excruciatingly painful if you need to make a change or add a commit to an earlier part of the “stack”. Now you have to manually rebase everything after it one by one by one.