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

Question

How can I tell mercurial that a remote server (originally on bitbucket for example, but they no longer support Mercurial) 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]
publish = 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

Gernhard

A good point, and I suspect one better to raise on the mailing list. Maybe a change to outgoing so it lists if a chageset will change phase is necessary. – Indicator

Note for future viewers of this question: BitBucket now have the option to configure the repository to non-publishing.. In such case, doing what the OP asked for would be unnecessary.. I suspect the need for this will subside.. for example, Mozilla user repositories are non-publishing since Feb 2015 (mozilla-version-control-tools.readthedocs.org/en/latest/…) – Ekg

For bitbucket specifically (as that is tagged), you can configure this in the repository’s settings. – Mesial

The documentation now says "publish = False" not "publishing = false" – Posset

The example with bitbucket repos is obsolete because bitbucket no longer supports hg repos since 2020. – Leath

@Leath I have removed the bitbucket tag and added comment. Very unfortunate state of afairs at Atlassian abandoning mercurial users after previously expressing commitment to mercurial. We use a local Heptapod instance now, which indeed does not have this issue. – Gernhard

@mforbes: Yeah I used to host my projects on bitbucket too. Heptapod was still in an early stage when I migrated things, and too much on the complex side to self-host, so I had my partner spin up a hgweb instance that runs to this day (which is at hg.pushbx.org now). I have been considering applying for hosting on foss.heptapod.net but it would be just another mirror at this point. – Leath

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.

Norvol

I agree that the correct thing to do is to set the server, but I can't (version 1.9, and I don't have authority). Unlike your counterexample, however, what I am suggesting does not affect the server, so I see no reason why such a local override should not be available (on a need-to-use-because-the-server-is-broke basis). After all, I can painfully achieve the same effect by manually re-phasing. To answer your questions: the server would ignore the client as in the 1.9 case when it does not know about phases. This is about local management only. – Gernhard

I don’t see how requiring the receiver to participate makes sense, especially with hosting services. In a hosting service, it may be very possible and easy and supported by everyone to create a private branch which only you have access to but impossible to mark it as non-publishing because the hosting provider has not implemented it yet. It’d be natural to be able to mark that as a nonpublishing remote in ~/.hgrc. – Mesial

Answer 2

I know this question is 10 years old, but just now I had exactly this requirement, a very old Mercurial server, which doesn't even know about phases (all its repos are always publishing), where I wanted to create a review repository.

I found the answer in this old mail thread:

The idea is, you have a public repository (here called <public>), which contains all public commits, and you install pull and push hooks which change all those local commits to draft, that are NOT on this public repo.

[hooks]
post-push = hg phase --force --draft 'public() and outgoing(<public>)'
post-pull = hg phase --force --draft 'public() and outgoing(<public>)'

Obduce