6 ms·

Thanks that makes sense - just feels weird to go from years of “be very careful rewriting history with git, especially at work” to jj rewriting everything all t

Thanks that makes sense - just feels weird to go from years of “be very careful rewriting history with git, especially at work” to jj rewriting everything all the time - can’t shake the feeling there’s a clash somewhere waiting to happen

cube2222 2y ago
You can customize the immutable commits option to specify which commits you want to be blocked from changing. By default that’s only the main branch and untracked remote branches. For me that makes sense as I’m generally fine with constantly rewriting my feature branches. However, if you want it to e.g. block you from rewriting anything that you’ve already pushed to the remote, you can set it to treat anything that’s pushed to the remote as immutable, too, as another commenter described [0]. [0]: https://news.ycombinator.com/item?id=42940329 https://news.ycombinator.com/item?id=42940329
gcr 2y ago
As long as you don't use `--allow-backward` or `--ignore-immutable`, and as long as everyone sticks to their own feature branches, this shouldn't be possible. The operation log makes jj quite safe. There's a command to restore the entire working copy + history to an earlier state in case you screw something up. Even this operation log is itself versioned, so you can undo the undo if you screwed the undo up, ad infinitum. :)
- ashenke 2y ago
  For every feature we usually have two developers working on it, one frontend and one backend, working on the same feature branch. Would Jujitsu cause a problem in this context?
  - stouset 2y ago
    I haven't used this workflow personally, but it should be fine. `jj git push` does an equivalent to `--force-with-lease`, so if there are remote commits that are later than what your current bookmark points to, it won't overwrite them. You can `jj git fetch`, it'll update your bookmark, and you can choose to put your new commits onto the updated sequence of commits wherever they belong.
  - steveklabnik 2y ago
    Just to be clear, as with git, you don’t have to rebase. It’s just that doing so is nicer in jj. But if rewriting commits on a shared branch becomes onerous, don’t do that!

cube2222 2y ago

You can customize the immutable commits option to specify which commits you want to be blocked from changing. By default that’s only the main branch and untracked remote branches. For me that makes sense as I’m generally fine with constantly rewriting my feature branches. However, if you want it to e.g. block you from rewriting anything that you’ve already pushed to the remote, you can set it to treat anything that’s pushed to the remote as immutable, too, as another commenter described [0]. [0]: https://news.ycombinator.com/item?id=42940329 https://news.ycombinator.com/item?id=42940329

gcr 2y ago

As long as you don't use `--allow-backward` or `--ignore-immutable`, and as long as everyone sticks to their own feature branches, this shouldn't be possible. The operation log makes jj quite safe. There's a command to restore the entire working copy + history to an earlier state in case you screw something up. Even this operation log is itself versioned, so you can undo the undo if you screwed the undo up, ad infinitum. :)

ashenke 2y ago
For every feature we usually have two developers working on it, one frontend and one backend, working on the same feature branch. Would Jujitsu cause a problem in this context?
- stouset 2y ago
  I haven't used this workflow personally, but it should be fine. `jj git push` does an equivalent to `--force-with-lease`, so if there are remote commits that are later than what your current bookmark points to, it won't overwrite them. You can `jj git fetch`, it'll update your bookmark, and you can choose to put your new commits onto the updated sequence of commits wherever they belong.
- steveklabnik 2y ago
  Just to be clear, as with git, you don’t have to rebase. It’s just that doing so is nicer in jj. But if rewriting commits on a shared branch becomes onerous, don’t do that!