Comments

As requested. Since I can't fault the code, I'll nit-pick the documentation. Coding standards require that function summaries should start with a third-person present indicative verb, and fit on a single 80-character line.

From the first patch:

+ * Change the default branch.

Should perhaps be:

+ * Changes the default branch.

+ * Get the default branch of the repository. That is the branch HEAD points
+ * to.

Should perhaps be:

+ * Gets the default (HEAD) branch of the repository.

+ * Ensure that the default branch stays set after it has been changed.

Should perhaps be:

+ * Ensures that the default branch stays set after it has been changed.

Very happy to see somebody stepping up for this kinda stuff. Unfortunately I have to crush this a bit with many additional requirements, but @Niklas Fiekas was pretty gracious about that in irc :) brief summary of those issues:

We cannot assume direct writability to repositories on-disk. While it may be possible in certain configurations, it isn't possible on d.o (repositories are not locally available to webheads), and isn't advisable in any case (webserver shouldn't have write access to your git repos). To deal with this, we currently use a layer of indirection for async requests (such as setDefaultBranch()) that passes through a job queue, and is picked up by workers on the other side. This works kinda well enough for the async write situation. It's not robust enough to really deserve the title 'framework,' but it's good enough to not require rearchitecting.

Direct reads from the repository have no real support at the moment - at least, not when triggered from the web ui. The assumption with such reads are that they're a blocking request - the process handling the web request needs to have that data in order to render the page. getDefaultBranch() is an excellent example of this. This is a very different kind of challenge than the async one. It's already a requirement, though, for the new, Drupal-native version of a repository browser to go in. GitHub uses BERT, an RPC system, to do it; we're looking at a node.js-backed solution. The transport layer doesn't really matter that much, though, tbh.

Actually, getDefaultBranch() isn't something we necessarily want to require a blocking network + io call. We still need the sync framework described above, but for this specific case, it would be better to have the data stored locally - we can treat that as canonical of the user's preference, which lets us clean up any potential anomalies on disk. Doing that means adding a {versioncontrol_git_repositories} table, with a default_branch field, and corresponding CRUD to the various entities that manage it (VersioncontrolGitRepository, VersioncontrolGitRepositoryController. We could do this with an overridden controller or a hook, but I prefer overriding).

All that said, I don't really mind keeping these methods on the VersioncontrolGitRepository object itself; they make logical sense as part of the API. But they need to connect to these indirection layers instead of doing the work directly themselves.

The original 6203 update created the table, but it did not create records in that table for each currently existing repository. As a result, no subsequent update operations work as they assume those records to already exist.

Please add a 6205 update that creates records, even if they're empty ones, for all (git) repositories.