http://drupal.org/project/worker/git-instructions

worker has not master branch and has no default set
looking in the select you can see only one branch yet master is display

Seems like it should default to the first branch in combo if no default is selected.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

boombatower’s picture

Project: Project Git instructions » Version Control API -- Git backend
Version: 6.x-1.x-dev » 6.x-2.x-dev

Tracked this through code from
http://drupalcode.org/project/project_git_instructions.git/blob/refs/hea...

to

http://drupalcode.org/project/versioncontrol_git.git/blob/HEAD:/includes...
http://drupalcode.org/project/versioncontrol_git.git/blob/HEAD:/includes...

Which is where "master" is coming from. Seems like the default could use to be a bit more sophisticated, otherwise the code above needs to know to read the setting from http://drupal.org/node/1702952/edit/default-branch. but either way seems like the versioncontrol_api should at least return a branch that exists.

helmo’s picture

As a quick fix the git instructions code could check in the list of branches if the returned default branch actually exists.

But it would indeed be nicer to get this fixed in the API.

marvil07’s picture

Title: When default branch is not selected (and not master) invalid branch is displayed » Set default branch from reposync default plugin
Status: Active » Needs review
Issue tags: +needs forward port to Drupal 7
FileSize
6.42 KB

Thanks for the report.

The real problem is that provide reposync plugin is not setting the default branch on first read, and yes, master should not be assigned as magical default.
So, instead of trying to figure it out dynamically on the getter, this patch solves the problem setting the value on the reposync plugin.

I think I need to test it on staging to be completely sure.

In the other side, it's possible to fix default values through a hook_update_N(), but it will take a lot, since we need to examine at least all repositories using master as default(as a queued operation, but yeah, a lot of repositories).

sdboyer’s picture

+++ b/includes/VersioncontrolGitRepository.php
@@ -131,14 +131,30 @@ class VersioncontrolGitRepository extends VersioncontrolRepository {
+   *   - 'persist': On TRUE it writes to git repository, on FALSE it just set
+   *     the value on the object.

I'm not sure that I like making this distinction, at all. From the perspective of the public API, I would prefer that a 'set' operation will always ensure that it is set both in the db and in the repo on disk.

if anything, we should enqueue the set operation and NOT update the db, instead relying on the queued operation to update the db once the disk has definitively been updated.

+++ b/includes/plugins/reposync/VersioncontrolGitRepositoryHistorySynchronizerDefault.class.php
@@ -88,6 +88,12 @@ class VersioncontrolGitRepositoryHistorySynchronizerDefault implements Versionco
@@ -682,4 +688,21 @@ class VersioncontrolGitRepositoryHistorySynchronizerDefault implements Versionco

@@ -682,4 +688,21 @@ class VersioncontrolGitRepositoryHistorySynchronizerDefault implements Versionco
     }
     return TRUE;
   }
+
+  protected function getDefaultBranch() {
+    $exec = 'symbolic-ref --quiet HEAD';
+    $logs = $this->execute($exec);
+    $default_branch = next($logs);
+
+    if (empty($default_branch)) {
+      return NULL;
+    }
+
+    // Stdout should be refs/heads/<branchname>.
+    if (!preg_match('/^refs\/heads\/(.*)$/', $default_branch, $match)) {
+      return NULL;
+    }
+
+    return $match[1];
+  }

bleh. since we can't guarantee synchronous access to the repository via the normal VersioncontrolGitRepository::getDefaultBranch() method, i guess i'm ok with this. still icky, though.

marvil07’s picture

Version: 6.x-2.x-dev » 7.x-1.x-dev
Assigned: Unassigned » marvil07
Issue tags: -needs forward port to Drupal 7 +Needs backport to D6
FileSize
5.93 KB
7 KB

I also really did not like the persist option. It was actually the chicken/egg problem that confused me :-)

After making another review on this, I think I have the right solution.

Here the notes from the commit I'll be adding once it pass the tests:

  • Lets {versioncontrol_git_repositories}.default_branch to be NULL.
  • Renames VersioncontrolGitRepository default_branch data member to defaultBranch. Also changes its visibility to public to be able to change it from outside (i.e. reposync plugin).
  • Adds a getDefaultBranch() method to VersioncontrolGitRepositoryHistorySynchronizerDefault to retrieve the default branch from git.
  • Set the default branch to database on reposync default plugin.
  • Adds a note to remove VersioncontrolGitRepository::getDefaultBranch() in the next major version.
marvil07’s picture

Status: Needs review » Fixed

Not sure why testbot is not testing the patches here :-(, anyway I runned the tests locally, and added it to D7 and with a minor hook_update_N N change to D6.

marvil07’s picture

Issue tags: -Needs backport to D6

rm tag

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

  • Commit 8d949c7 on 7.x-1.x, fix-invalid-default-branches, fullsync-memory by marvil07:
    Issue #1796382: Set default branch from reposync default plugin.
    
    - Lets...