3 ms·

> The subsequent revisions are updated automatically How do you make sure, that a commit isn't changed under you, because someone thought, it would be a good i

> The subsequent revisions are updated automatically How do you make sure, that a commit isn't changed under you, because someone thought, it would be a good idea to change an earlier revision? I think having immutable commits including all the previous history is a feature, not a bug.

nchmy 1y ago
Jj treats any public/pushed commits/branches as immutable by default.
- 1718627440 1y ago
  How does it know that? Does it also work, when I clone or pull instead? Is that only enforced on the committer side? I mean git also doesn't force push by default, but that still means someone else can do that and I need to notice it.
  - nchmy 1y ago
    I don't have answers for you. But the docs are useful and people in their discord are helpful as well
  - stouset 1y ago
    There is a way to express which sets of revisions are immutable. This uses the revset feature which itself a whole amazing thing that hasn’t come up in the conversation yet. This is a mechanism by which you can concisely express and refer to entire sets of commits in your repo history, and lots of commands can operate on multiple revisions as easily as they can operate on one. Just like git, it is only enforced by the tool itself on the client side. But it’s safer in practice because `git push -f` is a common habit when you’re working on a branch by yourself and it’s easy to fat-finger that in the wrong place. I have only ever had to use `jj --ignore-immutable` when explicitly doing repo surgery. If you want branches like `main` to be truly immutable, you need to enforce that at the repo.
MrJohz 1y ago
JJ has a concept of mutable and immutable changes. Typically, mutable changes are ones that you're currently working on locally. If you create a branch locally and push to it, then the changes on that branch will also be considered mutable. But changes created by other people in branches that you didn't create are considered immutable, as are e.g. changes that already exist in the default branch. There are a handful of other ways that you can convert changes between the two states, but generally the distinction is fairly intuitive: mutable changes are ones that you own, and where it would normally be "safe" to force push etc, and immutable changes are ones that probably also exist on someone else's machine. All changes can be modified, but if you try and update a change marked as "immutable", then Jujutsu will error out unless you provide a specific flag. This generally provides a lot of protection against unexpected rebases from other people. You also have a local immutable history of every update to your copy of the repo. This includes fetches/pulls, so you can easily see and undo those changes if something does go wrong along the way. But if people are deliberately force-pushing to master, you're going to end up in weird states whatever to you use.

nchmy 1y ago

Jj treats any public/pushed commits/branches as immutable by default.

1718627440 1y ago
How does it know that? Does it also work, when I clone or pull instead? Is that only enforced on the committer side? I mean git also doesn't force push by default, but that still means someone else can do that and I need to notice it.
- nchmy 1y ago
  I don't have answers for you. But the docs are useful and people in their discord are helpful as well
- stouset 1y ago
  There is a way to express which sets of revisions are immutable. This uses the revset feature which itself a whole amazing thing that hasn’t come up in the conversation yet. This is a mechanism by which you can concisely express and refer to entire sets of commits in your repo history, and lots of commands can operate on multiple revisions as easily as they can operate on one. Just like git, it is only enforced by the tool itself on the client side. But it’s safer in practice because `git push -f` is a common habit when you’re working on a branch by yourself and it’s easy to fat-finger that in the wrong place. I have only ever had to use `jj --ignore-immutable` when explicitly doing repo surgery. If you want branches like `main` to be truly immutable, you need to enforce that at the repo.

MrJohz 1y ago

JJ has a concept of mutable and immutable changes. Typically, mutable changes are ones that you're currently working on locally. If you create a branch locally and push to it, then the changes on that branch will also be considered mutable. But changes created by other people in branches that you didn't create are considered immutable, as are e.g. changes that already exist in the default branch. There are a handful of other ways that you can convert changes between the two states, but generally the distinction is fairly intuitive: mutable changes are ones that you own, and where it would normally be "safe" to force push etc, and immutable changes are ones that probably also exist on someone else's machine. All changes can be modified, but if you try and update a change marked as "immutable", then Jujutsu will error out unless you provide a specific flag. This generally provides a lot of protection against unexpected rebases from other people. You also have a local immutable history of every update to your copy of the repo. This includes fetches/pulls, so you can easily see and undo those changes if something does go wrong along the way. But if people are deliberately force-pushing to master, you're going to end up in weird states whatever to you use.