Heptapod 0.6.1 released
We're glad to announce the release of Heptapod 0.6.1, on Docker Hub.
This version contains several fixes that improve the reliability of imports for mature projects and handles the closing of named branches properly. It also re-enables the import from Bibutcket as a beta feature.
The full changelog can be read online alongside the Dockerfile and in the full description of the images in Docker Hub.
Also, in the same timeframe, our public development instance is now open to registration.
Beta: import from Bitbucket
GitLab CE sports a feature to import projects from Bitbucket, that we had to disable early in the Heptapod project, because it could not work at the time for Mercurial repositories.
Besides the repository itself, the GitLab Bitbucket import takes care of issues and Merge Requests. We didn't test the latter yet.
With the "import from URL" ready in Heptapod 0.6.0, we expected the full Bitbucket import to be around the corner. And indeed, it was.
The work we did for Heptapod 0.6.1 about the Bitbucket import does not go far beyond making the option visible again, and declaring that Mercurial repositories are indeed importable.
Since it worked so easily, we found it appropriate to make it available to our users right away. We don't expect it to work for all projects, but it's a start, and if it works for you, then you're all set.
If you come across problems, we'll be glad to hear about them in our issue tracker, especially if your case is easy to reproduce (small public project).
Of course we'll upstream any relevant fix to GitLab.
Closing heads
The primary goal of closing a branch is to stop seeing it by default. One can hence consider that it was a bug of Heptapod 0.6.0 not to remove the branch from the GitLab interface.
Also commit --closes-branch has been used a lot in the past to clean up multiple heads conditions, and because of that, not discarding closing changesets from the GitLab side was an impediment for the good operation of Heptapod. Indeed, counting the closed heads as multiple heads prevented new updates of the branch on the GitLab side or even its creation in imports.
In particular, the results we got while testing the import of the PyPy project, with its 16 closed heads on the default branch alone did not leave any room for doubt.
All of this is controlled by two new HGRC flags, whose names speak for themselves.
Backwards compatibility
With 0.6.1, by default, pushing the closing of a branch will have it removed from the GitLab interface, but nothing happens to closed branches or heads that have already made their way to GitLab.
Nevertheless, if you'd like to keep the previous behaviour, you can use the following HGRC snippet:
[experimental] hg-git.prune-previously-closed-branches = no hg-git.prune-newly-closed-branches = no
Breaking change scheduled for 0.7.0
We plan for 0.7.0 to remove all closed heads or branches from GitLab. This will be done by changing the default value of the relevant HGRC flag.
If you want to stick with the 0.6.1 behaviour, just use the following HGRC snippet:
[experimental] hg-git.prune-previously-closed-branches = no