Closed (fixed)
Project:
Version Control API -- Git backend
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
27 Sep 2012 at 08:37 UTC
Updated:
26 Mar 2014 at 15:02 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
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 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 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 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 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 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 commentedrm tag