FR: Add support for marking a branch or multiple commits immutable

[PhilipMetzger]

This is a feature request which stems from the conversation which started here in Discord.

Summary:
We discussed the issue of having a release branch in which all history should be immutable, as only cherry-picks can be added. This could be done via static configuration in the repository, which imposes some kind of merging mechanism for configuration, as there may be multiple remotes with different immutable branches. Or having a per user revset which determines when a revision is immutable.

Related work for this feature are Sapling's Phases and Mercurial's Phases.

Additionally a revset to determine the main branch in the repository and a configuration based revset to determine what an release branch is, would be nice.

A suggestion was adding some kind of globbing mechanism e.g glob(release/*) or some kind of template like
release(2022-21-1).

[martinvonz]

Can you summarize that Discord discussion? I skimmed it, but I'm not sure what you want to define the release branches for. There was some discussion about having a configurable set of branches or a configurable revset in order to prevent accidental rewriting. Is that what you want?

#1415 will involve defining a main branch.

[PhilipMetzger]

I've updated the feature request with a summary.

[martinvonz]

I've updated the feature request with a summary.

Thanks, and thanks for updating the title too.

This could be done either like Mercurial's phases or as a configurable revset. Phases are exchanged between remotes on push/pull and always move forward, IIRC. Phases imply a shared view of which commits are immutable. Some considerations:

• A configurable revset requires more work from the user. We can provide a reasonable default (probably remote_branches()) to help a bit.
• Configurable revsets probably make it easier for the user to shoot themselves in the foot.
• What do we want the library crate to do with immutable commits? My feeling is that it should not care about it; the feature is there to help prevent the user from accidentally rewrite commits.
• A configurable revset is easier to implement.
• There's already support for phases (well, public and draft phase anyway) in the model. There's a public_heads() revset function, but it only includes root.
• If we add support for phases (or at least public and draft), we'll need a way to exchange them. For Git remotes, we would probably implement it as a set of branches that should be considered as public.
• Revsets are more flexible and could prevent the user from accidentally modifying other users' commits by configuring a revset like main | (main.. & ~author(me)) (ancestors are implied).

I'm not sure which is better, but I think we should remove the public_heads() revset until we've decided. I also think a revset is a good first step even if we decide to add support for phases later.

[PhilipMetzger]

A part of this is adressed by #2297 and another part by #2088, now the missing part is the revset for release branches.

[martinvonz]

A part of this is adressed by #2297 and another part by #2088, now the missing part is the revset for release branches.

I was about to close this as completed by #2297 because that seemed like the essence of this FR. I was going to instead open a new FR for the support for globbing in revsets, but I think that's also done (#2407) :)

[PhilipMetzger]

Basically these points are still unadressed:

Additionally a revset to determine the main branch in the repository and a configuration based revset to determine what an release branch is, would be nice.

But I can open another FR for each of them.

[martinvonz]

But I can open another FR for each of them.

Feel free. I do think they seem quite loosely related to the main feature in this FR, so I prefer to keep them separate. I found it misleading that canonical FR for adding support for immutable commits was still open.

[PhilipMetzger]

Ah, for the first one there's already #2943. I'll create them.