Running composer install on each checkout can be quite slow as it still need to do a dependency resolution each time, even if nothing has changed. IMO, you should first check if the composer.lock file changed (for the case where it is versionned, it is the only check needed). This can be achieved as the hook receives the old HEAD and the new HEAD and so we can do a git diff between them on the lock file.

ping @RobLoach? :)

@RobLoach @stof This might do as a fairly basic diff of the old and new composer.lock:

# -e is supposed to inhibit all output but it doesn't...
( git cat-file -e "$1:composer.lock" >/dev/null 2>&1 ) && ( git cat-file -e "$2:composer.lock" >/dev/null 2>&1 ) && ( git diff --quiet "$1:composer.lock" "$2:composer.lock" ) && exit

(Might not correctly handle all the different combinations of composer.json and/or composer.lock existing or not between the two branches. So many edge cases...)

Might also be useful if this doc also contained a sample post-install-cmd script that installed the post-checkout hook into .git/hooks/post-checkout.

I did that in my dotfiles: https://gist.github.com/lyrixx/5867424
and more over, I added that to all of my projects: lyrixx/dotfiles@5d1b6c0

@lyrixx Cool! I think the conditional can be simplified to:

if git diff --quiet $PREV_COMMIT..$POST_COMMIT composer.lock ; then
  ...
fi

None of these solutions help with the problem of a git pull updating composer.lock, but that isn't the hook's fault...

@ithinkihaveacat Are you sure ? because it works git rebase.

@ithinkihaveacat simply does a similar hook for post-merge

@lyrixx @stof Ah, yes it seems git rebase triggers the post-checkout hook, and git pull triggers post-merge. So maybe both hooks will cover all git-powered modifications of composer.lock.

There are just so many different places and workflows how Composer could live. composer, composer.phar, php composer.phar, etc. The script handling workflow can get pretty hairy. It would be nice to translate this to PHP as well, to hopefully clean up the bash a bit.

@stof Unfortunately, post-merge doesn't get the pre/post merge refs, so it can't be used to perform a conditional composer install.

@ithinkihaveacat A merge commit allows to know both parent commits, and IIRC, it even allows knowing which one was the commit of the current branch and which one was the commit of the merged branch

for a post merge, it is probably a matter of doing a git diff HEAD^...HEAD

@stof Thanks, I'll experiment. There's also the fast-forward "merge" situation to consider.

Did the ultimate composer git hook script get published in the end?

Not sure. Ping @RobLoach? Is anyone actually using this successfully? I'd like to get real world feedback before adding it to the docs.

Didn't end up using it. Having the installation as part of the git hook seems undesired. Might be good to just assume it's at composer? What are your thoughts?

@Seldaek I just display a message if composer.json is different. And yes it's work very well, and it's very important for me.

@lyrixx would you care to take over this PR and share your solution? It sounds like a superior solution to warn but not automatically update. Don't you warn on composer.lock changes though?

That's a much more graceful solution, agreed. Thanks, you two.

@Seldaek Sorry. I mean when the composer.lock change. I prefer a warning over an action, because sometime (actually often), I switch to another branch just to try something, and I don't want to update my vendored lib.

You can have a look to this file
and this commit to enable this hook to all my repositories.

BTW, you can run git init to an existing repository to setting up theses hooks.

Anyway, as this issue is closed, what could I do for you?

I suggest you open a new PR adding your hook to the documentation (well, minus the chef check of course)