4 ms·

My understanding of jj is that's it's meant to be compatible with git. Does that mean that working through this will also improve your git usage? Or could be u

by sn9 1y ago

My understanding of jj is that's it's meant to be compatible with git. Does that mean that working through this will also improve your git usage? Or could be used to teach someone git workflows?

baq 1y ago
Haven’t reviewed the material, but compatible is a weak word - jj is also compatible with a plain filesystem. The point is that it makes some workflows easy and accessible which are hard and cumbersome in git, so they become the new normal instead of things to avoid.
nchmy 1y ago
You'd only really learn anything if you know nothing. The underlying git is largely invisible, and the workflows are vastly different - for the better. It is constantly making new git commits any time you use a jj command. (I even have it set up to use watchman to create commits any time any file changes - this is unimportant for this discussion). But the commits are completely hidden - we instead interact with jj "changes", which are more like a constantly evolving, auto-adding, auto-committing, stash-free, movable git commit. Git branches are even a 2nd class citizen. We can create endless "branches" by adding new changes on top of any existing change, and then merge that with an arbitrary amount of other changes by specifying them when creating a new change. We can also rebase/move changes around all over the place, and the changes get automatically propagated through any descendents. We can also split and squash commits very easily, and even do so on a granular level - easily and interactively select lines or sections of changed code within one change to be split or squashed into a different change. This allows you to just work, and then tidy the history up later when you have a clue. Conflicts that arise from merge/rebase/split/squash/etc do not require immediate intervention - fix them when you want to, and the fix will also propagate through. You can use jj resolve to open the conflicts in your merge conflict editor of choice (I use vs code). We use git branches when we apply/update a jj bookmark to any change. This essentially creates/changes a git branch, which can then be pushed to Github. When bookmarks are pushed, the ancestor changes become "immutable" by default, which prevents things like editing, rebasing etc, so as to facilitate collaboration. But it can be override, and I presume it does things like a force push for you. One thing to note is that your jj "branches" etc are not shared as it just stays local. You could, in theory, sync your .jj folder remotely, but I don't see that being particularly feasible unless it's just to sync with another device for your own use (or back it up in case of data loss). It's really just a local interface for individual use, and collaboration still happens via git branches and pull requests. If you were to lose your jj folder, you could clone the git repo again and you'd just start with the existing git branches etc. I'll mention one particularly powerful/useful jj workflow - the megamerge. There's a few detailed articles out there if you search for it, and they've been discussed on hn as well (I'm on phone so can't be bothered). It allows you to merge numerous feature "branches" (again, jj branches, which are optionally also git branches if you use bookmarks) into a new branch, which lets you easily work on top of the combined functionality of various branches that are in progress. You can then interactive squash changes into their respective feature branches prior to the empty megamerge commit/change. There's also jj absorb, which does this interactive squash in a sort of magical, automatic way (though I find that sometimes it just doesn't do anything) There's so much more to say about it, but overall you just don't need to think about git at all and instead just think about your code, and then tidy up the history etc as-needed, without much cognitive overhead or friction. This is all made even easier by the absolutely fantastic https://github.com/idursun/jjui https://github.com/idursun/jjui TUI. It's largely "just" a wrapper with shortcuts over jj commands and their resulting output. But it makes what's already simple absolutely seamless. I hope this helps. Jj and jjui are absolutely beautiful. Ignore all the luddites who try to say "if it's just git under the hood, then I'll just keep using that myself, thank you very much". I never intend to "raw dog" (as the kids say) git again. I do use some git mechanisms in vscode though - merge conflict resolution, diff visualization (it shows whatever has changed in the current jj change)
- terminalbraid 1y ago
  What does Luddite mean to you?
  - nchmy 1y ago
    It's peculiar that you singled-out that specific sentence from my entire comment. I sense a trap being laid, but I'll bite anyway. Luddites were skilled craftspeople who are afraid of technology/progress supplanting them, which is largely what is happening when people reject jj in favour of arcane git incantations as part of a vastly more laborious git workflow. The biggest way in which this label does not apply here, is that luddites were also primarily fighting for their economic positions, which were of course completely threatened by new technology. Whereas jj doesn't cost anyone anything - its just a toolbox and way of operating that just makes you more efficient. My point still stands, regardless of how fitting the label was. Luddite would more directly apply to (probably the same set of people) those who are completely against ai/llms for any degree of coding, as it clearly has the potential to eliminate jobs. Though, of course, the most experienced and skilled people are well-positioned to leverage llms as cheap junior devs who can be instructed, guided, corrected etc to produce what is needed. It new, less-skilled devs/apprentices who would be most justified in fighting against LLMs, under the Luddite banner. Though we tend to see that they embrace llms most
    - 8n4vidtmkvmk 1y ago
      The unskilled devs don't have any skills to fall back on. I don't know how they can afford to be luddites. The skilled ones will be fired if they don't embrace it.
    - palata 1y ago
      > which is largely what is happening when people reject jj in favour of arcane git incantations JJ is interesting, though I find some things worse than git (no email workflow, and nothing that does what `git add -p` does. In the article, it shows the limitation of the TUI for `jj split`). But what I don't get is seemingly all those people who seem to believe that git is rocket science. Yes, JJ seems in a good position to become nicer than git. But git is not hard. I don't get that part at all. So many comments saying "I have been using git for 15 years, yet I don't understand what detached HEAD / stash / git add -p / some not-so-complicated concept means".
emporas 1y ago
Every jj action is translated to a git action, but the git protocol is used only as a low level filesystem underneath, completely abstracted away. Akin to how C abstracts assembly as far I understand. No need to know assembly to use C.

by sn9 1y ago

My understanding of jj is that's it's meant to be compatible with git. Does that mean that working through this will also improve your git usage? Or could be used to teach someone git workflows?

baq 1y ago

Haven’t reviewed the material, but compatible is a weak word - jj is also compatible with a plain filesystem. The point is that it makes some workflows easy and accessible which are hard and cumbersome in git, so they become the new normal instead of things to avoid.

nchmy 1y ago

You'd only really learn anything if you know nothing. The underlying git is largely invisible, and the workflows are vastly different - for the better. It is constantly making new git commits any time you use a jj command. (I even have it set up to use watchman to create commits any time any file changes - this is unimportant for this discussion). But the commits are completely hidden - we instead interact with jj "changes", which are more like a constantly evolving, auto-adding, auto-committing, stash-free, movable git commit. Git branches are even a 2nd class citizen. We can create endless "branches" by adding new changes on top of any existing change, and then merge that with an arbitrary amount of other changes by specifying them when creating a new change. We can also rebase/move changes around all over the place, and the changes get automatically propagated through any descendents. We can also split and squash commits very easily, and even do so on a granular level - easily and interactively select lines or sections of changed code within one change to be split or squashed into a different change. This allows you to just work, and then tidy the history up later when you have a clue. Conflicts that arise from merge/rebase/split/squash/etc do not require immediate intervention - fix them when you want to, and the fix will also propagate through. You can use jj resolve to open the conflicts in your merge conflict editor of choice (I use vs code). We use git branches when we apply/update a jj bookmark to any change. This essentially creates/changes a git branch, which can then be pushed to Github. When bookmarks are pushed, the ancestor changes become "immutable" by default, which prevents things like editing, rebasing etc, so as to facilitate collaboration. But it can be override, and I presume it does things like a force push for you. One thing to note is that your jj "branches" etc are not shared as it just stays local. You could, in theory, sync your .jj folder remotely, but I don't see that being particularly feasible unless it's just to sync with another device for your own use (or back it up in case of data loss). It's really just a local interface for individual use, and collaboration still happens via git branches and pull requests. If you were to lose your jj folder, you could clone the git repo again and you'd just start with the existing git branches etc. I'll mention one particularly powerful/useful jj workflow - the megamerge. There's a few detailed articles out there if you search for it, and they've been discussed on hn as well (I'm on phone so can't be bothered). It allows you to merge numerous feature "branches" (again, jj branches, which are optionally also git branches if you use bookmarks) into a new branch, which lets you easily work on top of the combined functionality of various branches that are in progress. You can then interactive squash changes into their respective feature branches prior to the empty megamerge commit/change. There's also jj absorb, which does this interactive squash in a sort of magical, automatic way (though I find that sometimes it just doesn't do anything) There's so much more to say about it, but overall you just don't need to think about git at all and instead just think about your code, and then tidy up the history etc as-needed, without much cognitive overhead or friction. This is all made even easier by the absolutely fantastic https://github.com/idursun/jjui https://github.com/idursun/jjui TUI. It's largely "just" a wrapper with shortcuts over jj commands and their resulting output. But it makes what's already simple absolutely seamless. I hope this helps. Jj and jjui are absolutely beautiful. Ignore all the luddites who try to say "if it's just git under the hood, then I'll just keep using that myself, thank you very much". I never intend to "raw dog" (as the kids say) git again. I do use some git mechanisms in vscode though - merge conflict resolution, diff visualization (it shows whatever has changed in the current jj change)

terminalbraid 1y ago
What does Luddite mean to you?
- nchmy 1y ago
  It's peculiar that you singled-out that specific sentence from my entire comment. I sense a trap being laid, but I'll bite anyway. Luddites were skilled craftspeople who are afraid of technology/progress supplanting them, which is largely what is happening when people reject jj in favour of arcane git incantations as part of a vastly more laborious git workflow. The biggest way in which this label does not apply here, is that luddites were also primarily fighting for their economic positions, which were of course completely threatened by new technology. Whereas jj doesn't cost anyone anything - its just a toolbox and way of operating that just makes you more efficient. My point still stands, regardless of how fitting the label was. Luddite would more directly apply to (probably the same set of people) those who are completely against ai/llms for any degree of coding, as it clearly has the potential to eliminate jobs. Though, of course, the most experienced and skilled people are well-positioned to leverage llms as cheap junior devs who can be instructed, guided, corrected etc to produce what is needed. It new, less-skilled devs/apprentices who would be most justified in fighting against LLMs, under the Luddite banner. Though we tend to see that they embrace llms most
  - 8n4vidtmkvmk 1y ago
    The unskilled devs don't have any skills to fall back on. I don't know how they can afford to be luddites. The skilled ones will be fired if they don't embrace it.
  - palata 1y ago
    > which is largely what is happening when people reject jj in favour of arcane git incantations JJ is interesting, though I find some things worse than git (no email workflow, and nothing that does what `git add -p` does. In the article, it shows the limitation of the TUI for `jj split`). But what I don't get is seemingly all those people who seem to believe that git is rocket science. Yes, JJ seems in a good position to become nicer than git. But git is not hard. I don't get that part at all. So many comments saying "I have been using git for 15 years, yet I don't understand what detached HEAD / stash / git add -p / some not-so-complicated concept means".

emporas 1y ago

Every jj action is translated to a git action, but the git protocol is used only as a low level filesystem underneath, completely abstracted away. Akin to how C abstracts assembly as far I understand. No need to know assembly to use C.