If `@` turns immutable, it can still be mutated

[mlcui-corp]

Description

If @ somehow turns immutable - for example, if immutable_heads() contains remote_branches(), and @ is pushed - @ can still be mutated.

GitHub's "Adding new commits" workflow discourages force-pushing new commits, so for those repositories I've added remote_branches() to immutable_heads().

Steps to Reproduce the Problem

1. Have remote_branches() in immutable_heads().
2. jj git push -c @ --remote mlcui
3. Change the working copy.

Expected Behavior

Changing the working copy does not work. I'm not too sure what the nicest way of doing so would be:

• Automatically creating a new empty change on top if @ becomes immutable, then committing things to that.
• Having a divergent @ change.

Actual Behavior

@ is modified, even though it is immutable.

Specifications

• Platform: Ubuntu 22.04.2 LTS running under WSL
• Version: jj 0.14.0-82b3017fdaabbb60823ad133e37d980223054381

[PhilipMetzger]

I think this is expected, as I wrote in the section:

Warning We strongly suggest to jj new after the example below, as all further edits still get amended to the previous commit.

$ # Create a new commit on top of the your-feature branch from above. $ jj new your-feature $ # Address the comments by updating the code. Then review the changes. $ jj diff $ # Give the fix a description. $ jj describe -m 'address pr comments' $ # Update the branch to point to the current commit. $ jj branch set your-feature -r @ $ # Push it to your remote $ jj git push

the commit will only be considered immutable after a new following the fetch. This is because there is no sync in-between.

[martinvonz]

Yes, this is expected, but we can probably do better. I suppose one option is to check at the end of each command to see if any working-copy commit is now immutable and then create a new working-copy commit for it.

[PhilipMetzger]

Yes, this seems to be a good choice, although I'd expect that we print a message before creating a new wc-commit.

[martinvonz]

I'd expect that we print a message before creating a new wc-commit.

Yes, I would also expect that.

[mlcui-corp]

I suppose one option is to check at the end of each command to see if any working-copy commit is now immutable

This should work in this specific instance, but there may be cases where @ could turn immutable before a command is run. For example:

• if the immutable_heads() config option was manually modified to include @,
• in a Git colocated repository, if @ was somehow imported as a branch / ref which would be matched by the immutable_heads() revset.

Creating a new working copy commit at the end of a command makes it clear to the user that they're now working in a new commit. Applying the same solution to the cases where @ turns immutable before a command is run might be more confusing. This may be even more confusing if a filesystem watcher like watchman is enabled - when should the "new WC" message appear?

[PhilipMetzger]

I suppose one option is to check at the end of each command to see if any working-copy commit is now immutable

This should work in this specific instance, but there may be cases where @ could turn immutable before a command is run. For example:

• if the immutable_heads() config option was manually modified to include @,
• in a Git colocated repository, if @ was somehow imported as a branch / ref which would be matched by the immutable_heads() revset.

I think both of those are erroneous configurations, @ never should be in the immutable_heads() revset.

Applying the same solution to the cases where @ turns immutable before a command is run might be more confusing. This may be even more confusing if a filesystem watcher like watchman is enabled - when should the "new WC" message appear?

I don't think that going in the opposite direction is a good idea, as it will confuse everyone. We really should only check after a transaction to see if we're in the immutable_heads() revset.

[joyously]

We really should only check after a transaction

Any special case for undo?

[PhilipMetzger]

We really should only check after a transaction

Any special case for undo?

I don't think that it should be necessary, I could be wrong though.

[tdaron]

Hi !

Any news on this issue/help wanted for implementation ?

I am also quite annoyed about this behavior as I keep editing pushed commits after forgetting to create a new one, and in some cases with some workflows I don't really want to be able to do this.