3 ms·

Been 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 octo

Been 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 weird at first, but now I don't want to go back to git. It feels a bit like the step from SVN to git back in the the day. ("this feels weird" -> "how did people ever tolerate the old way?")

conaclos 2y ago
> The auto committing behavior is a bit weird at first I am a bit skeptical about this, because this requires a jj daemon?
- abhinavk 2y ago
  No from what I see. It does that whenever you run any jj command. I haven't checked the source.
  - sheremetyev 2y ago
    by default snapshotting happens on each jj command additionally you can enable automatic snapshots when files in the working copy are updated: https://martinvonz.github.io/jj/latest/config/#watchman https://martinvonz.github.io/jj/latest/config/#watchman
- aseipp 2y ago
  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/facebook/watchman/ https://github.com/facebook/watchman/ in order to have a truly daemon-ified option where any filesystem write will cause a snapshot to be taken.
  - stouset 2y ago
    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.
steveklabnik 2y ago
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!
- stouset 2y ago
  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.
stouset 2y ago
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.
atoav 2y ago
To me at least it makes so much more sense to be like: 1. I am going to work on $X 2. autocommit 3. My work on $X is done rather than 1. I make changes 2. I am done making changes 3. Now I have to describe what I changed and how Maybe this is just me, but with git it is at times hard at times to hit the right balance in terms of commit granularity — and for my flow planning forward ("I am gonna do $X") rather than describing what I did ("I did $X") seems more.. focused?

conaclos 2y ago

> The auto committing behavior is a bit weird at first I am a bit skeptical about this, because this requires a jj daemon?

abhinavk 2y ago
No from what I see. It does that whenever you run any jj command. I haven't checked the source.
- sheremetyev 2y ago
  by default snapshotting happens on each jj command additionally you can enable automatic snapshots when files in the working copy are updated: https://martinvonz.github.io/jj/latest/config/#watchman https://martinvonz.github.io/jj/latest/config/#watchman
aseipp 2y ago
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/facebook/watchman/ https://github.com/facebook/watchman/ in order to have a truly daemon-ified option where any filesystem write will cause a snapshot to be taken.
- stouset 2y ago
  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.

steveklabnik 2y ago

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!

stouset 2y ago
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.

stouset 2y ago

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.

atoav 2y ago

To me at least it makes so much more sense to be like: 1. I am going to work on $X 2. autocommit 3. My work on $X is done rather than 1. I make changes 2. I am done making changes 3. Now I have to describe what I changed and how Maybe this is just me, but with git it is at times hard at times to hit the right balance in terms of commit granularity — and for my flow planning forward ("I am gonna do $X") rather than describing what I did ("I did $X") seems more.. focused?