1

I'm trying to write a simple pre-commit hook to check if a file was modified, if so, compress it and add it into the current index, something like this

#!/bin/sh                                                                                                                                                    

# was the file modified?
mf='git status | grep jquery.detectBrowser.js'

# is the non-compressed file in the staging area?
if [ $mf != "" ]
then
  # alert the user
  echo "Javascript file modified, YUI Compressor will begin now."

  # go to rhino
  cd $HOME/apps/rhino/yuicompressor-2.4.7/build

  # compress my file
  java -jar yuicompressor-2.4.7.jar ~/www/jquery.detectBrowser.js/jquery.detectBrowser.js -o ~/www/jquery.detectBrowser.js/jquery.detectBrowser.min.js

  # comeback to the initial directory
  cd -

  # add the new file into the index
  git add ~/www/jquery.detectBrowser.js/jquery.detectBrowser.min.js
fi

I have 2 issues, 1 my condition is failing, every time, I must have a typo or something like that, but I can't figure out what it is? This is the error I get back:

[: 23: git: unexpected operator

And my second problem is that even if I remove the condition the file is never actually ADDED into the commit, it's modified, but never ADDED.

Thanks, Leo

leopic
  • 2,958
  • 2
  • 27
  • 42
  • 1
    `git diff --cached` displays changes that are already in the index. Perhaps you want just regular `git diff` instead? Also, if you have any other un-added files, your conditional will fail. Plus, it should be `==` instead of `=`. You probably really want to be `grep`ing for the file you're looking for, not using `==`. – Amber Dec 12 '11 at 06:45
  • Thank you Amber, I've updated the post to reflect your feedback. – leopic Dec 12 '11 at 06:59
  • @Amber: I think the OP *does* only want to do this if the changes to that file are staged. It's a little vague though. – Cascabel Dec 12 '11 at 07:12

1 Answers1

3

Your error is because you're not quoting $mf. Change it to "$mf". Though there are perhaps better ways than grepping the output of a human-readable command... you could have a look at git status --porcelain for example. Or even git diff --cached <path>, and just examine the exit code, e.g.:

if ! git diff --quiet --cached <path>; then
     # the file was modified; do stuff
fi

I think Amber may have misled you: you should use --cached, because if the changes are not staged, then as far as this commit is concerned, there are no changes, so I assume you don't want to do anything else.

And of course, I don't know your project, but I'm not sure why you're doing something like this - usually you don't want to check in machine-generated content, just make it easy to rebuild from what is checked in.

As for your last problem, the file being modified but not added to the commit, I can't reproduce it with a toy example. I made this as a pre-commit hook:

#!/bin/bash
touch z
git add z

and made a commit, and z was as expected created, added, and committed.

Cascabel
  • 479,068
  • 72
  • 370
  • 318
  • I totally agree on not adding machine generated content into a repository, the thing here is that this is a jQuery plugin and I'd like to offer both a non-compressed and a compressed version of the file, whatever the user wants to go with, it's their choice. – leopic Dec 12 '11 at 07:34
  • 1
    @LEOPiC: Are your *users* getting these things by cloning the repo, yet unable to run a single command to do this? That's unusual. There are two normal things you do to deal with any sort of machine-generated content: make it an easy part of a "build" process (i.e. clone the source, run one command, done), and using that, make it part of your distribution/deployment/packaging process (create the compressed version and toss it into the tarball). – Cascabel Dec 12 '11 at 15:56
  • Well not all projects have an ant associated with them, I do get your point of view, totally, in the company we work for we have separate build processes for each environment consisting of several ant tasks each, but this being a one off and since this plug-in is more targeted to Front-End people I believe a case can be made about having a minified version available is valid. – leopic Dec 13 '11 at 16:47
  • 1
    All right, just giving some general advice, but it's your workflow! (What about your real question? I believe I've fixed your test, and verified that the pre-commit add should work...) – Cascabel Dec 13 '11 at 16:56
  • I appreciate it, I really do, regarding my real question, I still can't get the file to appear consistently every time I modify it, any ideas of what might be happening? Not sure if there is a log or something I can provide. – leopic Dec 13 '11 at 17:45
  • 1
    @LEOPIC: You say it's inconsistent? That's... strange, to say the least, since Git commands are pretty derministic. I would try printing more diagnostic output from your script - you have an echo to confirm you're inside the `if`; once you know the conditional is working right, you could run `git status --porcelain` before and after the `git add`, as well as before and after you run `git commit`, to see where things diverge from expected state. – Cascabel Dec 13 '11 at 17:57
  • What I did is totally removed the condition and try to run it everytime, it won't work unless I source the file, which works the first time, but it won't work again unless I source it again. – leopic Dec 13 '11 at 18:05
  • 1
    "source the file" - you're... sourcing the hook? I'm confused. You're testing this by modifying jquery.detectBrowser.js, staging that change, and committing, right? Also, it's kind of bizarre that you're using absolute paths in the script - are all those paths actually within your repository? Hooks are invoked from the top level of the repo, so you should be able to use relative paths. – Cascabel Dec 13 '11 at 18:09
  • It was totally my bad, for some reason I wasn't checking the actual contents of the commit, but only the default message, thus the file always appeared as untracked, when I tested again today, the file was indeed committed, thank you for your help! – leopic Dec 15 '11 at 04:21