Fatal when trying to call git from hook

[WiseBird]

I am getting fatal: Not a git repository: '.git' when trying to call git from hook: "precommit": "git status". I think the reason is that my package.json isn't located in root folder and hook is run from there.

The only way I found is to prepend each git call with cd ../../../.

[iamstarkov]

hi @WiseBird, its hard for me to get the problem. can you create a github repo with minimal reproducible test case?

[WiseBird]

@iamstarkov here it is
Install packages and then try to run git commit -m "X"

And here you can see a workaround.

[jspiro]

I'm seeing this too. If I call a bash script in a subdirectory below the package, and that script calls git status, it doesn't work despite the working directory being correct and sibling to .git.

[jspiro]

Ah, in my case it was because I was setting $GIT_DIR in my script, which is apparently a reserved env var. $GIT2_DIR made it go away. So maybe my issue is unrelated.

[tamoyal]

im having this problem as well

[oakley808]

I'm seeing this too. I'm in a monorepo where my .git/ folder is up many levels from my package.json file, similar to the example from @WiseBird above.

Update: Looks like my issue was actually in the task I was running. Upgrading lint-staged seems to fix the issue for me.

[tnguyen14]

I am running into this issue as well. This happens because the node app is a child directory of the git repository. My guess is that it is caused by lint-staged, so I created an issue there lint-staged/lint-staged#170

[prathees]

I had the similar problem (lint-staged to be run on a sub-directory within the main project). Following issue and its solution , resolved it.

#167

[hallettj]

Like others I am seeing the variable setting GIT_DIR=.git. I do not see GIT_DIR set when running other npm scripts. But it is set when I use Husky to run a precommit script. I am not using lint-staged.

[JonasGroeger]

I used "postcommit": "cross-env GIT_DIR=../.git git update-index --again",

[egucciar]

GIT_DIR did not work for me. It seems to want to leverage the .git within the same folder....getting this:
"precommit": "yarn docs && cross-env GIT_DIR=../../.git git add README.md"

fatal: Unable to create 'subdirectory/stuff/.git/index.lock': No such file or directory

This did:

"precommit": "yarn docs && cd ../../ && git add subdirectory/stuff/README.md"

[AlexWang-16]

Just for documentation purposes, I want to share my experience of this same issue while building a docker image for my project.

Here's the setup of my directory

Root Dir/

• .git/
• server/
• client/

with server/ and client/ with their own package.json. I have husky installed in server and client folder respectively and got the fatal error while I was building the image.

I took inspiration from @egucciar and changed my precommit script to do cd ../ before my designated precommit command and it seemed to work.

This is how my precommit command looks: "pre-commit": "cd ../ && pretty-quick --staged"

[testerez]

Looks like the issue(?) is in git itself. Pretty easy to reproduce:

mkdir test-precommit
cd test-precommit
git init
mkdir dir
echo "echo GIT_DIR=\$GIT_DIR" >> .git/hooks/pre-commit
echo "cd dir" >> .git/hooks/pre-commit
echo "git status" >> .git/hooks/pre-commit
chmod +x .git/hooks/pre-commit
git commit -m test

Output:

GIT_DIR=.git
fatal: not a git repository: '.git'

[testerez]

Adding unset GIT_DIR at the top of my hook scripts did the trick for me. I'd be interested at understanding the reasoning behind this GIT_DIR though...

[fatso83]

Shouldn't the workaround for this issue just be documented and then closed?

I don't see how this can be fixed in a non-breaking way. If Husky would manipulate GIT_DIR to an absolute path, it would probably break quite a few scripts that relied on its relative nature. And if Husky won't change it, while it also needs to set the current working directory to the sub-dir for Node to work, I can't see this being fixed from Husky alone.

That means either

• set GIT_DIR yourself before running npm scripts, as above (possibly using crossenv)
• Change your scripts to do it themselves the way Husky does it.

[fatso83]

Example of dealing with this issue: fatso83/check-commit-msg@9385d85

• I use GIT_PREFIX to find out where the frontend project is - relative to the git root
• I use that knowledge to adjust all relative file paths that assume we are at the root
• I update GIT_DIR to be an absolute path for all subsequent git commands to work

[FDiskas]

I'm using

zsh 5.4.2 (x86_64-ubuntu-linux-gnu)
npm 6.9.0
node v10.16.0
git version 2.17.1
---
Kernel Version: 4.18.0-21-generic
Operating System: Ubuntu 18.04.2 LTS
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 15.44GiB

Project structure

.
├.git
└ current
   └─ package.json

if I run GIT_DIR=../.git lint-staged --debug I get

Running git command [ 'rev-parse', '--show-toplevel' ]
2019-06-12T12:51:01.083Z lint-staged:run Resolved git directory to be `/home/*censored*/Projects/*censored*/*censored*/current`

if I run lint-staged --debug I get

lint-staged:git Running git command [ 'rev-parse', '--show-toplevel' ]
Current directory is not a git directory!

if I run just command in current directory in terminal git rev-parse --show-toplevel
I get correct path to root. 🐄

[fatso83]

Turns out just adjusting GIT_DIR and/or GIT_PREFIX does not fix all cases, as these environment variables are not available in all git hooks. I needed to use findUp to find the right parent folder containing the .git dir. If you need a template, have a look at this fix:

fatso83/check-commit-msg@79c82b9

The tool is a commit hook that is run by Husky's as the commitmsg script, which should be relatable for a lot of these issues.

[xanonid]

For me, an upgrade of git to version 2.23.0 (from 2.17.1) solved this wrong GIT_DIR problem - did not tried versions between. The issue seems to be really a problem in older git versions as @testerez suggested.

[fatso83]

@xanonid Could you try running the little script by @testerez and dump its output? It would be interesting to see what the differences are between 2.17 and 2.23. If anything, I would assume that they have changed GIT_DIR from a relative path (.git) to absolute (/home/johndoe/dev/proj/.git). Unfortunately, 2.17 is the latest version on Ubuntu 18.04.3 LTS.

In any case, relying on your users to have the latest Git version is a bit haphazard, so I'd suggest having the script find the right .git root itself, as suggested above.

[kauanmocelin]

After update git from 2.17.1 to 2.26.2(last version) this problem "GIT_DIR" was fixed for me.

[marcstreeter]

in my case I have a monorepo with python for the api and javascript/react for the frontend (very similar structure to the other comments here). I am/was using pre-commit for git hooks on the python side, and I was trying to use husky for the javascript side (I realize that pre-commit could do the javascript side too, but I like husky auto-installing with the rest). Anyways I found that my husky hooks are getting removed when I install the python pre-commit library. It outputs the following

Running in migration mode with existing hooks at .git/hooks/pre-commit.legacy

which I believe would mess up any scripts husky has going that would refer to the original .git/hooks/pre-commit

Does anyone run husky and pre-commit together in harmony?

[marcstreeter]

sigh... I think I found the "solution" on stack overflow. This seems to push you more to using pre-commit, which isn't bad but definitely not what I was hoping.

[fatso83]

@marcstreeter We have a monorepo with a mix of Go, Python, Java and Javascript. We have actually made a common/git-hooks directory that is fully controlled by Husky. It contains both Node and Bash scripts. Works fine, and we resorted to this as we thought mixing two different libs that try to do the same thing is just asking for trouble.

[marcstreeter]

@fatso83 that sounds awesome, could you point me in any direction for how to do that? I didn't know husky could drive commit hooks for other programming languages

[fatso83]

Remember that any NPM script is just a command line that gets executed. There is nothing that says it has to be JavaScript. For instance, it is quite common to invoke make, rm and other standard Unix tools on the path. There is nothing preventing you from having an NPM script called prepush that simply is python ../../my-hooks/lint-python-stuff.

[typicode]

Closing as v5 doesn't have this issue. Thanks for the workarounds/solutions regarding v4 :)