I am using pre-commit to invoke flake8 with a plug-in flake8-requirements.
The plug-in currently requires flake8 to be invoked in the package root, which conveniently isn't the repo root. Per this comment in a pre-commit issue, I have accordingly modified my pre-commit config to be this:
- repo: local
hooks:
- id: flake8
name: flake8 src package
alias: flake8-src
files: ^src/
types: [python]
language: system
entry: bash -c "cd src && flake8"
This works properly. Unfortunately, the src package is large, and flake8 takes a few seconds to run. So, now pre-commit runs are not snappy.
How can one tweak the entry such that the files from pre-commit (passed as positional args) are passed to flake8?
Update: or am I wrong, and this works already as intended?
flake8-requirements seems like not the greatest plugin -- it relies on needing to have access to your entire codebase at once so you can't really get beyond the "it's going to be slow" and have flake8-requirements at the same time.
personally I would split the flake8-requirements check out to a separate check and probably not run it as part of pre-commit (because it is so slow)
also, I noticed you're not using the official flake8 configuration and instead ~reinventing the wheel with a repo: local hook. as such you've unintentionally written a fork bomb :)
disclaimer: I'm the current flake8 maintainer and I created pre-commit
I noticed with git log origin/master that new a commit is up.
So I want to "see" this commit on my local repo.
I do this
$ git fetch -v
From xxx.xxx:proj/test
= [up to date] master -> origin/master
Everything seems fine... But nothing has changed on my local repo !?
To update your branches (as opposed to your Git's memory of some other Git's branches—git fetch updates this memory only), you must run a second Git command.
The second command to run is sometimes git merge and sometimes git rebase, depending on how you prefer to work. If you have no preference yet, use either one until you do have a preference.
There is a convenience command spelled git pull, that runs both git fetch and then the second command. The second command it runs is the one you tell it to. You must configure it based on your choice of second command to use. I recommend avoiding this until you really understand what the second command is and does, because eventually something will go wrong when running the second command. If you do not know that git pull is running this second command, you will not only not know what to do about this failure ... you won't even know that you need to look for how to fix problems with the other command!
I am attempting to make use of this gist in my workflow as post-merge and post-checkout git hooks.
#!/usr/bin/env bash
# MIT © Sindre Sorhus - sindresorhus.com
# git hook to run a command after `git pull` if a specified file was changed
# Run `chmod +x post-merge` to make it executable then put it into `.git/hooks/`.
changed_files="$(git diff-tree -r --name-only --no-commit-id ORIG_HEAD HEAD)"
check_run() {
echo "$changed_files" | grep --quiet "$1" && eval "$2"
}
# Example usage
# In this example it's used to run `npm install` if package.json changed
check_run package.json "npm install"
This claims to only run npm install if the package.json file is changed.
However on all the machines I have tried this on. The npm install command runs regardless of whether package.json has been changed or not.
To test this I have been creating a new branch at my current commit and then checking it out, thus triggering the post-checkout git hook. I would not expect npm install to run because the package.json is unchanged.
Visual Proof (note the npm warning text):
ORIG_HEAD should be replaced with HEAD#{1} as noted in this question ORIG_HEAD is an older, less reliable way to supposedly get the previous state of HEAD. In my case it was not being set.
TL;DR
Use a different post-checkout hook, that uses $1 instead of ORIG_HEAD. (Or, check the number of arguments to decide whether you are being invoked as the post-checkout or post-merge hook, to get the same effect. Or, if you know that reflogs are always enabled, use HEAD#{1} to get the previous value of HEAD.)
Discussion
Using ORIG_HEAD in a post-merge hook makes sense, because git merge sets ORIG_HEAD to the commit that was current before the merge. (If the merge was a true merge, rather than a fast-forward, the commit identified by MERGE_HEAD and the commit identified by HEAD^1 are necessarily identical. If the merge was a fast-forward, however, only MERGE_HEAD and the reflog will be able to locate the previous commit hash that was stored in HEAD before the merge.)
Using ORIG_HEAD in a post-checkout hook, however, is blatantly wrong, because git checkout does not set ORIG_HEAD. This means that if ORIG_HEAD even exists at all, it effectively points to some random commit. (Of course, it actually resolves to whatever commit was left in it by whatever command last updated it: git merge, git rebase, or any other command that writes to ORIG_HEAD. But the point here is that it does not have any relationship to the commit that was current before the checkout.) A post-checkout hook:
is given three parameters: the ref of the
previous HEAD, the ref of the new HEAD (which may or may not have
changed), and a flag indicating whether the checkout was a branch
checkout (changing branches, flag=1) or a file checkout (retrieving a
file from the index, flag=0). This hook cannot affect the outcome of
git checkout.
(That last sentence is not quite right. Although the post-checkout hook cannot stop checkout from having updated the index and work-tree, it can overwrite various work-tree or index contents, and if it produces a failure exit status, it causes git checkout itself to also produce a failure exit status.)
What this all means is that you need to take a different action in a post-checkout hook: use $1, the first parameter, to get the hash ID of the previous HEAD. Note that in exotic cases,1 the post-checkout hook is run on the initial git clone, so $1 can be the null-ref. (I'm now curious as to what it is when you use git checkout --orphan and then don't create the new branch, as well. It seems likely that $1 will be the null-ref here too.)
1The only way to get a post-checkout hook to run on git clone is to have git clone install the post-checkout hook. This is normally impossible, but can be done by pointing your Git to your own template directories that have actual hooks instead of just sample hooks.
Torek mentions:
This hook cannot affect the outcome of git checkout.
That last sentence is not quite right.
Although the post-checkout hook cannot stop checkout from having updated the index and work-tree, it can overwrite various work-tree or index contents, and if it produces a failure exit status, it causes git checkout itself to also produce a failure exit status.
That is now (Q4 2020, 3 years later) officially documented with With Git 2.29:
See commit 3100fd5 (27 Aug 2020) by Junio C Hamano (gitster).
(Merged by Junio C Hamano -- gitster -- in commit 2f1757e, 03 Sep 2020)
doc: clarify how exit status of post-checkout hook is used
Because the hook runs after the main checkout operation finishes, it cannot affect what branch will be the current branch, what paths are updated in the working tree, etc., which was described as "cannot affect the outcome of 'checkout'".
However, the exit status of the hook is used as the exit status of the 'checkout' command and is observable by anybody who spawned the 'checkout', which was missing from the documentation.
Fix this.
githooks now includes in its man page:
This hook cannot affect the outcome of git switch or git checkout,
other than that the hook's exit status becomes the exit status of these two commands.
I made a checkout to the previous commit and all local changes (neither staged nor commited) were gone. Is there a way to recover those local changes?
Sergey - there are only a handful of commands that can nuke your working directory changes. git checkout -f is one of them (git reset --hard is another). I would not recommend you ever use that form as your default. Use git checkout instead. If that fails (which it will if you have changes), then use git status and git diff to look at the changes you have, and either save them off (commit or stash), or explicitly throw them out.
How can I check if git has successfully cloned a repository, and based on that result, execute commands inside the bash script?
I was trying some combinations of grep checking the output of git status but I've only managed to confuse myself more.
I'm ruining timeout 60s git clone ... so I must make sure the repository has cloned fully, and if it has not to skip whatever it would have done with the cloned data.
Have a look at it.
I think You are expecting this code.
https://stackoverflow.com/a/13715406/2959196
Also Have a look at the conversation. It might help you better.
How to detect if a git clone failed in a bash script
Your timeout command will return a non zero exit code if it terminates the program. Use that rather than checking the repository to see if it's cloned.