Pages tagged with: "git"

(Coding) How to resolve a conflict in Git by choosing {theirs}

Very quick aide-memoire for me: to quickly choose {theirs} when faced with a Git conflict, just do:

git checkout HEAD [filename]



Drupal: strange MySQL "table doesn't exist" error caused by CCK, Features and Strongarm

Ran into a bit of a strange error today; I was getting a Drupal "table not found" SQL error on my live site after pushing an updated feature from the dev site, and then reverting the feature to get the settings back to default.

The query was:

user warning: Table 'greyhead.node_field_instance' doesn't exist query:
SELECT * FROM node_field_instance nfi 
LEFT JOIN node_field nf ON nf.field_name = nfi.field_name 
WHERE = 1 AND nfi.widget_active = 1 
in <noodle foo bar>/sites/all/modules/cck/content.install on line 187.

... So I dived into the CCK module's content.install and line 187 called this function: content_instance_tablename(), which I tracked down to content.module, where the function calls this: variable_get('content_schema_version', 0);

On both dev and live sites, this returns 6009, so the content_instance_tablename() function should return a value of content_node_field_instance, but instead seems to be returning a value which is evaluating to < 6001; i.e. the function returns the old CCK schema table name of node_field_instance, and this breaks any queries which rely on this value.

Putting two and two together, my guess was that Strongarm is over-writing the content_schema_version value in the {variable} table at some point during the execution of certain pages, which is breaking CCK's variable_get call.

So I hopped over to the command line to look into the feature files for "content_schema_version"; cd'ing to the feature's directory, I ran:

grep -irn "content_schema_version" *

... which showed that the variable was defined in the feature:

That Strongarm value

... but that it was providing the right value of 6009. At this point I figured that I was likely to be running into a strange issue being caused by the variable_get running during a variable_set, or some other such voodoo-based weirdness. Easy solution? Remove the field's definition from the feature and allow CCK to look after provision of that variable au-naturel.

So, in the end I simply recreated the feature from the live site (admin > build > features > greyhead settings > recreate) and under the Strongarm drop-down, unticked the checkbox for content_schema_version. Then I re-exported the feature and unpacked it into my MAMP localhost install, did a git commit on the localhost followed by a git push, the over on the server did a git pull, followed by drush cc all and a drush updatedb, just for good measure. Finally, I had to run variable_set('content_schema_version', 6009); using the Devel module.

Touch wood, so far, I haven't seen that error since.

Very odd...


Attached files: 

Amateur geeknote: see which Git repository branch you're currently in at the command prompt

This is a very cool little tip from Lullabot (down the page under "What branch am I on?") for those of you using Git on the command line which allows you to see which repository branch you&#39;re currently in via the command prompt. Simply add this code to the ~/.bash_profile file (or create it if you don&#39;t already have it):

## Bash prompt
function parse_git_branch {
  git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1)/'

function proml {
  local        BLUE="\[\033[0;34m\]"
  local         RED="\[\033[0;31m\]"
  local   LIGHT_RED="\[\033[1;31m\]"
  local       GREEN="\[\033[0;32m\]"
  local LIGHT_GREEN="\[\033[1;32m\]"
  local       WHITE="\[\033[1;37m\]"
  local  LIGHT_GRAY="\[\033[0;37m\]"
  case $TERM in

$BLUE[$RED\$(date +%H:%M)$BLUE]\
$GREEN\$ "
PS2='> '
PS4='+ '

Open a new Terminal shell and your command prompt should now look a little different. Try cd'ing to a directory containing a git repo and you should see the branch name shown. Handy stuff, innit?

You might want to tweak the colours a bit to suit your tastes; if you manage to break anything, you can always revert the file back (perhaps put it into it's own mini Git repo...?). If you come up with a better colour scheme, please let me know!


Syndicate content