How do I tell (locally) mercurial that a server is non-publishing?

Question

How can I tell mercurial that a remote server (on bitbucket for example) is non-publishing when I do not have access to the remote .hg/hgrc file?

Background

Recent versions of mercurial has a concept of phases that allow one to keep track of which changesets have been shared (public) and which ones have not (draft). Repository changing operations like rebase are allowed on draft changesets, but not public changesets as others might depend on the latter.

Pushing changesets to a public server will change their phase to public by default, but if the server is private or dedicated to code reviews (i.e. people should not be able to pull), then pushing to that "non-publishing" server should not change the phase.

The documented way of telling mercurial that the server is non-publishing is to add a [phases] section to the .hg/hgrc file on the server:

[phases]
publishing = false

It seems to me that there should be a way of including a line in one of my local hgrc files that says a particular server is non-publishing, but I cannot find any documentation to suggest how. Perhaps this behaviour could be customized with a hook?

References

• https://www.mercurial-scm.org/wiki/Phases
• Introduction to Mercurial Phases
• After pushing to a review repository, "abort: can't rebase immutable changeset" on rebase

Answer 1

There is currently no way to do that and it should hopefully never happen.

Here is why:
If you allow the local repository to override the remote repository configuration, you are just making the whole phase mechanism useless. The point of the phases is to prevent user to perform actions that could "corrupt" the synchronization flow.
It the responsibility of the receiver to describe how the received changesets will be used. If you invert that logic, by allowing the sender to override these settings, then, how can you ensure that two senders will use the same configuration? If the configuration differ, which one should be kept? How should the changesets be marked on the receiver?

To some degree, it would be the same as if a local repository was able to push changesets to a remote without being authorized, just by overriding the remote configuration locally.