Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comment | File | Size | Author |
---|---|---|---|
#5 | 0001-Issue-1796382-Set-default-branch-from-reposync-defau.patch | 7 KB | marvil07 |
#5 | interdiff.txt | 5.93 KB | marvil07 |
#3 | 0001-Issue-1796382-Set-default-branch-from-reposync-defau.patch | 6.42 KB | marvil07 |
Comments
Comment #1
boombatower CreditAttribution: boombatower commentedTracked 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.
Comment #2
helmo CreditAttribution: helmo commentedAs 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.
Comment #3
marvil07 CreditAttribution: marvil07 commentedThanks 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).
Comment #4
sdboyer CreditAttribution: sdboyer commentedI'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.
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.
Comment #5
marvil07 CreditAttribution: marvil07 commentedI 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:
Comment #6
marvil07 CreditAttribution: marvil07 commentedNot 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.
Comment #7
marvil07 CreditAttribution: marvil07 commentedrm tag