2

I have a development setup like this: 

/themes/themename/css/style.css   # path to drupal theme css file
/styleguide/source/css/style.css  # path to generated css-file in styleguide

The styleguide has example markup for all different page types, and this is where design implementation is done. The drupal theme css file is tracked in git, and is updated in master from the css generated in the stylebuide. However, I constantly need to check that the style development also displays correctly in the drupal site, while I implement the design. I therefore have setup a softlink so that: 

/themes/themename/css/style.css -> /styleguide/source/css/style.css

This works nicely, I can just reload the web browser with the drupal view, and the newly generated css-file is loaded.

Currently I hide the fact that style.css is changed (for git), using: 

git update-index --assume-unchanged /themes/themename/css/style.css

However, whenever I do a git pull, or git checkout on an existing branch, git will complain, saying:

error: Your local changes to the following files would be overwritten by checkout:
themes/uib_w3/css/style.css
Please, commit your changes or stash them before you can switch branches.
Aborting

Any suggestions how I could avoid getting this message? Perhaps using some hook to reset the file on git pull, and the reestablish the link post pull? Or is there another approach to this that might work better?

jonasfh
  • 4,151
  • 2
  • 21
  • 37

1 Answers1

2

You could "abuse" a content filter driver in order to generate the right /themes/themename/css/style.css on checkout:

  • first, do not version style.css anymore: rename it as a "template".
    git mv style.css style.css.tpl.
    Add /themes/themename/css/style.css to your .gitignore.

  • second, add a smudge script associated to *.css.tpl files in a .gitattributes declaration:

    *.css.tpl  filter=checkcss

smudge
(image from "Customizing Git - Git Attributes", from "Pro Git book")

git config filter.checkcss.smudge 'style_smudge'

The style_smudge script can be versioned, and could be as simple as:

#/bin/sh
cat

In short: it does nothing to style.css.tpl on checkout.
But, you can use (abuse, really) that smudge script to do other things:

#/bin/sh
if [ -z ${dev+x} ]; then 
  ln -fs /styleguide/source/css/style.css /themes/themename/css/style.css
else
  cp -f /themes/themename/css/style.css.tpl /themes/themename/css/style
fi
cat

If an environment variable named "dev" is defined (to any value), then you are in "development" environment, and you need a symlink.
If that same variable "dev" is not set, then you keep your original style.css file.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • @VonC Out of curiosity why would this be considered an abuse of the feature? – Clive Jan 13 '16 at 17:55
  • @Clive because a *content* filter driver is supposed to modify the content of a filtered file. Here, we do not case about the content itself and are doing instead all kind of different operations. – VonC Jan 13 '16 at 18:44