Skip to content

Rewrapping of hg-git, writing directly in GitLab's Git repository

This is a complete rewrite of Heptapod specific hg-git logic, i.e, all that we had in the Heptapod fork that wasn't provided by hg-git upstream (hg-git#4 (closed))

By subclassing GitHandler, we can easily write directly in the target Git repository instead of writing to .hg/git first and concluding with a series of slow pushes. This solves heptapod#135 (closed) and halves the storage we use on top of Mercurial.

This MR targets the heptapod-0-8 branch but does not activate the new behaviour (the new hook has a different name). This has been started with Heptapod 0.8.4 in mind, but I realized that this much faster way of doing would trigger nasty race conditions in the merge detection: while nothing guarantees that our Git pushes are treated in order, the mere fact that we are somewhat slow between them was masking the problem. For Heptapod 0.12 (GitLab 12), these race conditions had to be fixed for good anyway.

Still it's been more comfortable to keep going in the heptapod-0-8 branch, be it to rebase test helpers and the like along the way.

In terms of workflow, merging in heptapod-0-8, and from there into default where it would be activated is probably the nicest way to go. If it turns out to be worth the effort, this could also be backported to Heptapod 0.8

Edited by Georges Racinet

Merge request reports