Unblock projects with a single GitLab branch being a topic
The problem
When a project starts its life as empty and the first pushed changeset is a topic, the following happens:
- The GitLab branch corresponding to the topic (what is seen as "branch" in the Heptapod UI) being the only GitLab branch of the project becomes automatically the default GitLab branch of the project. This is unavoidable: in GitLab, a non-empty project must have a default branch.
- The default GitLab branch being always protected, it cannot be deleted. On the other hand, pushing the publication of the topic would look as a GitLab branch deletion from the GitLab side (together with creation of its non-topical counterpart, usually
branch/default
), hence it is refused by the application. - Since there is no other GitLab branch at this point, there is no way to solve the problem by changing the default GitLab branch to something else.
Possible mitigations
None of this is surprising to people much accustomed to topics and Heptapod, and there are ways to get out of this double bind.
Here's for instance one:
- Push a second changeset with the same topic
- Publish the first changeset of the topic. This creates
branch/default
but does not delete the topic's GitLab branch. Moreover, Heptapod in this case automatically switches the default GitLab branch tobranch/default
. - Now that the GitLab branch for the topic is not the default GitLab branch, unprotect it (the stickiness of its protection is possibly something recent). We are finally in the normal situation, the topic can be fully published right away or through a MR etc.
BUT this is very confusing to new users of Heptapod or Mercurial with topics.
Human context
One may wonder why someone would have the weird idea of starting a project with a topic, especially when not used to them.
It happens when users have configuration that require all new changesets to have a topic (or enforce it by setting a random topic). The settings are truly useful to avoid involuntary publications in well established projects, and are therefore often set as part of new worker onboarding, or just shared by friendly colleagues. But they make quite of an impedance mismatch in this case.
The end effect to the user is that nothing works, while colleagues keep on repeating that everything is simple. In other words, it can be catastrophic in terms of user perception.
Solution
As mentioned above, Heptapod is already able to automatically switch the default GitLab branch away from a topic. The problem is just that the topic cannot be deleted in the same push. Actually what happens here is that branch protection has been tightened since the automatic switch was introduced.
Heptapod should in this case just bypass the branch protection. The precise criteria should be that the protected branch is for a topic that is undergoing publication, while still checking for publication rights. Both pre-receive
and post-receive
hooks should already carry the needed information about this.