Git pre-commit hook : changed/added files
Asked Answered
T

8

98

I am writing a pre-commit hook. I want to run php -l against all files with .php extension. However I am stuck.

I need to obtain a list of new/changed files that are staged. deleted files should be excluded.

I have tried using git diff and git ls-files, but I think I need a hand here.

Tuckie answered 9/3, 2010 at 20:49 Comment(2)
phpadvent.org/2008/dont-commit-that-error-by-travis-swicegoodRawlinson
That's pretty nice. It does not handle partially staged files however. See my comment to @LarryH's answer.Tuckie
T
59

git diff --cached --name-status will show a summary of what's staged, so you can easily exclude removed files, e.g.:

M       wt-status.c
D       wt-status.h

This indicates that wt-status.c was modified and wt-status.h was removed in the staging area (index). So, to check only files that weren't removed:

steve@arise:~/src/git <master>$ git diff --cached --name-status | awk '$1 != "D" { print $2 }'
wt-status.c
wt-status.h

You will have to jump through extra hoops to deal with filenames with spaces in though (-z option to git diff and some more interesting parsing)

Tobitobiah answered 9/3, 2010 at 22:39 Comment(6)
Thanks, that's a good start. However, if I change a file without staging it, it's still displayed. I am running git version 1.7.0.1.147.g6d84b (recent custom build). Not sure if this is intended behavior.Tuckie
That sounds odd. The "--cached" switch should make it only show files that have been staged: although I'm testing this with 1.6.5, it seems surprising that that would have changed... does "git diff --cached" on its own show the unstaged changes?Tobitobiah
After some debugging I was able to track it back to an other cause. Thanks a lot!Tuckie
@igorw, I would be interested but the link is dead.Sejant
Just to note if the only thing wanted is the name of the file, there exists--name-only instead of --name-status. Could cut the extra awk hoop.Fetter
The print $2 part of the awk command only works correctly if the file name doesn't contain spaces. One possible fix for this: ... | awk '$1 != "D" { $1=""; sub(FS,""); print $0 }'. Another note: for file renames, the git diff command prints OLD and NEW names. If only the new name is desired, add a --no-renames option to git diff, this will treat the rename as deletion of the old file and addition of the new file.Youthen
R
117

A slightly neater way of obtaining the same list is:

git diff --cached --name-only --diff-filter=ACM

This will return the list of files that need to be checked.

But just running php -l on your working copy may not be the right thing to do. If you are doing a partial commit i.e. just selecting a subset of the differences between your current working set and the HEAD for the commit, then the test will be run on your working set, but will be certifying a commit that has never existed on your disk.

To do it right you should extract the whole staged image to a temp area and perform the test there .

rm -rf $TEMPDIR
mkdir -p $TEMPDIR
git checkout-index --prefix=$TEMPDIR/ -af
git diff --cached --name-only --diff-filter=ACM | xargs -n 1 -I '{}' \bin\echo TEMPDIR/'{}' | grep \\.php | xargs -n 1 php -l

See Building a better pre-commit hook for Git for another implementation.

Recognition answered 18/6, 2010 at 10:53 Comment(3)
It is actually possible to pipe the file contents to php -l. And that's what we ended up with. See here: github.com/phpbb/phpbb3/blob/develop-olympus/git-tools/hooks/…Tuckie
To check the syntax of a staged file, you can use git show :FILENAME | php -l.Embrue
--diff-filter should probably be "ACMR", because renamed files (R) can have changes too.Changeling
T
59

git diff --cached --name-status will show a summary of what's staged, so you can easily exclude removed files, e.g.:

M       wt-status.c
D       wt-status.h

This indicates that wt-status.c was modified and wt-status.h was removed in the staging area (index). So, to check only files that weren't removed:

steve@arise:~/src/git <master>$ git diff --cached --name-status | awk '$1 != "D" { print $2 }'
wt-status.c
wt-status.h

You will have to jump through extra hoops to deal with filenames with spaces in though (-z option to git diff and some more interesting parsing)

Tobitobiah answered 9/3, 2010 at 22:39 Comment(6)
Thanks, that's a good start. However, if I change a file without staging it, it's still displayed. I am running git version 1.7.0.1.147.g6d84b (recent custom build). Not sure if this is intended behavior.Tuckie
That sounds odd. The "--cached" switch should make it only show files that have been staged: although I'm testing this with 1.6.5, it seems surprising that that would have changed... does "git diff --cached" on its own show the unstaged changes?Tobitobiah
After some debugging I was able to track it back to an other cause. Thanks a lot!Tuckie
@igorw, I would be interested but the link is dead.Sejant
Just to note if the only thing wanted is the name of the file, there exists--name-only instead of --name-status. Could cut the extra awk hoop.Fetter
The print $2 part of the awk command only works correctly if the file name doesn't contain spaces. One possible fix for this: ... | awk '$1 != "D" { $1=""; sub(FS,""); print $0 }'. Another note: for file renames, the git diff command prints OLD and NEW names. If only the new name is desired, add a --no-renames option to git diff, this will treat the rename as deletion of the old file and addition of the new file.Youthen
I
27

None of the answers here support filenames with spaces. The best way for that is to add the -z flag in combination with xargs -0

git diff --cached --name-only --diff-filter=ACM -z | xargs -0 ...

This is what is given by git in built-in samples (see .git/hooks/pre-commit.sample)

Inequality answered 20/2, 2017 at 13:5 Comment(0)
D
17

Here is what I use for my Perl checks:

#!/bin/bash

while read st file; do
    # skip deleted files
    if [ "$st" == 'D' ]; then continue; fi

    # do a check only on the perl files
    if [[ "$file" =~ "(.pm|.pl)$" ]] && ! perl -c "$file"; then
        echo "Perl syntax check failed for file: $file"
        exit 1
    fi
done < <(git diff --cached --name-status)

for PHP it will look like this:

#!/bin/bash

while read st file; do
    # skip deleted files
    if [ "$st" == 'D' ]; then continue; fi
    # do a check only on the php files
    if [[ "$file" =~ ".php$" ]] && ! php -l "$file"; then
        echo "PHP syntax check failed for file: $file"
        exit 1
    fi
done < <(git diff --cached --name-status)
Donalddonaldson answered 5/11, 2010 at 23:45 Comment(3)
Pretty good, but doesn't work for partially staged files, because it reads the whole file.Tuckie
Thanks ! I adapted your code and I put <<<$(git diff --cached --name-status) after the done instead using a pipe so that no subshell is started in the loop. It allows allowing variable updating in the loop to be used latter. Submitting an update of answer for review. BestMallen
cant edit my comment again so synthax is actually '< <$(command) like https://mcmap.net/q/218665/-propagate-value-of-variable-to-outside-of-the-loop-duplicateMallen
B
2

git diff --cached is not sufficient if the commit call was specified with the -a flag, and there is no way to determine if that flag has been thrown in the hook. It would help if the arguments to commit should be available to the hook for examination.

Bailment answered 10/9, 2015 at 17:16 Comment(3)
git diff --cached DOES appear to be sufficient. However, I believe that if you run git status --porcelain inside your hook, all the files that will be processed will not have a blank or a ? in the first position of the output. I haven't fully tested it, but so far, it has held up in all the conditions I have in my repo, a mix of new, added, modified files where I try to commit explicit files, the default set of files, -a for everything. So why use git status instead of git diff? I think it's easier to parse.Bailment
git status --porcelain | grep -E -v '^[? ]'Bailment
git status --porcelain | perl -ane 'print $F[1],qq(\n) if m/^[ACM] /' is a better answer. It has the advantage of using a --porcelain option, guaranteed to never change. Use your own parser if perl is too heavyweight for you.Bailment
R
1

to understand that the files have changed in a specific folder, I do this:

modifiedFrontendFiles=$(git diff --cached --name-status --relative=frontend)

if [ -n "$modifiedFrontendFiles" ]; then
    npm run lint
    npm run lint-css
    npm run format
    git add .
fi

in my case i check that the changes are in the frontend folder

Risteau answered 15/2, 2023 at 11:3 Comment(0)
R
0

eddygeek's answer cites the .git/hooks/pre-commit.sample example.

git diff --cached --name-only --diff-filter=ACM -z | xargs -0 ...

That example just changed with Git 2.44 (Q1 2024): the sample pre-commit hook that tries to catch the introduction of new paths that use potentially non-portable characters did not notice an existing path getting renamed to such a problematic path when rename detection was enabled.

See commit d9fd71f (30 Nov 2023) by Julian Prein (druckdev).
(Merged by Junio C Hamano -- gitster -- in commit 145336e, 20 Dec 2023)

hooks--pre-commit: detect non-ASCII when renaming

Signed-off-by: Julian Prein

When diff.renames is turned on, the diff-filter will not return renamed files (or copied ones with diff.renames=copy) and potential non-ASCII characters would not be caught by this hook.

Use the plumbing command diff-index instead of the porcelain one to not be affected by diff.rename.

So instead of:

git diff --cached --name-only --diff-filter=A -z $against

You now have, using git diff-index instead:

git diff-index --cached --name-only --diff-filter=A -z $against
Reglet answered 25/12, 2023 at 19:29 Comment(0)
M
0

If anyone is looking for pre-push check, then

git diff --name-only @{push}..

can be used.

Example:

monitored_folder="API/API.Site/Controllers"

changed_files=$(git diff --name-only @{push}..)

for file in $changed_files; do
    if [[ $file == $monitored_folder* ]]; then
        echo "Changes detected in '$monitored_folder'. Aborting push."
        exit 1
    else 
        echo $file;
    fi
done

Montmartre answered 23/4 at 6:30 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.