fatal: not a git repository when using checkout@v2

[DannyFriedmanQC]

I am trying to run git commands in an action using checkout@v2 but I am getting the error

fatal: not a git repository

My yaml looks like the following

name: name
on: [push, pull_request]
jobs: 
  some_job:
    name: some_name
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - name: some_name
         run: |
           git status

[GMNGeoffrey]

I'm experiencing something similar with my action that tries to git pull --ff-only origin master from within a submodule. I get an intermittent error

https://github.com/GMNGeoffrey/llvm-bazel/runs/1201180187
https://github.com/GMNGeoffrey/llvm-bazel/runs/1201199207
https://github.com/google/llvm-bazel/runs/1180737413
https://github.com/google/llvm-bazel/runs/1130264635
https://github.com/google/llvm-bazel/runs/1114116468

[chenrui333]

@DannyFriedmanQC can you attach your reference run (if possible)?

I have seen such errors before, I think it is more like github action performance issue.

[HebaruSan]

Seeing the same. No .git directory is created. Checked with a ls -la in the workflow to see what is there.

https://github.com/HebaruSan/NetKAN/runs/1534015545?check_suite_focus=true

total 168
drwxr-xr-x 5 1001  116   4096 Dec 10 23:14 .
drwxr-xr-x 6 root root   4096 Dec 10 23:14 ..
drwxrwxr-x 3 root root   4096 Dec 10 23:05 .github
-rw-rw-r-- 1 root root     50 Dec 10 23:05 .gitignore
-rw-rw-r-- 1 root root    210 Dec 10 23:05 .travis.yml
-rw-rw-r-- 1 root root   6502 Dec 10 23:05 LICENSE.md
drwxrwxr-x 3 root root 135168 Dec 10 23:05 NetKAN
-rw-rw-r-- 1 root root   1241 Dec 10 23:05 README.md
drwxrwxr-x 2 root root   4096 Dec 10 23:05 bin

[dopey]

Just wanted to add my voice and say that I'm seeing the same thing.

[HebaruSan]

After reading #335, removing this fixed it for me:

       container:
           image: ubuntu:latest

Somehow this was causing the wrong version of git to run. I don't pretend to understand why.

[rudolfbyker]

I'm also seeing this when using self-hosted runners on Windows Server. No .git directory is created. This causes all sorts of issues.

---

Edit:

Ah, I see there is a subtle warning message:

The repository will be downloaded using the GitHub REST API
To create a local Git repository instead, add Git 2.18 or higher to the PATH

🤔

---

Edit:

See #325

[DaniBencz]

After reading #335, removing this fixed it for me:

       container:
           image: ubuntu:latest

Somehow this was causing the wrong version of git to run. I don't pretend to understand why.

I don't understand it either, but removing my custom container from the job helped in my case, thanks!

[morlowska]

Removing

       container:
           image: …

isn’t solution here. If you remove this code, workflow will be run on your self-hosted machine itself, not in the container. It seems to work because on your machine you must have newer version of Git.

Ah, I see there is a subtle warning message:

The repository will be downloaded using the GitHub REST API
To create a local Git repository instead, add Git 2.18 or higher to the PATH

🤔

Edit:

See #325

according to this warning Git version should be higher than 2.18. So the real solution is to upgrade Git inside of your container’s image or, if version is already equal or higher than 2.18, add it to the PATH. Also there is another dirty workaround - after actions/checkout@v2 step run git init:

name: name
on: [push, pull_request]
jobs: 
  some_job:
    name: some_name
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - run: git init
      - name: some_name
         run: |
           git status 

but this initialize empty repository - git commands will work, but there will be no information about remote repository.

[jorgesolebur]

Hello ! I have same issue right now and I am not able to find a fix... it is killing me !
Quick question ( a little bit stupid but I need to do it to confirm this is not root cause): When you say "add Git 2.18 or higher to the PATH", what do you mean exactly ?
What I understand is that we should make sure we are adding the folder where git binary file is located in the PATH. How to do that?

We first run the following :

which git

The output is usr/bin/git. That tells us where git bin file is located (in folder located in usr/bin). Therefore if I run the following

echo $PATH

and I see the response includes the folder usr/bin, then I am supposed I am already including Git into the path, ins't it? Or am I missing anything else ? Is there anything else to be done?

My problem is that after verifying that git bin folder is included in path I am still having the issue. And the most surprising is that I do have a .git folder inside my project. Any help ?

$ls -la ./.git/
drwxr-xr-x 8 root root   4096 May 17 14:54 .
drwxr-xr-x 9 1001  121   4096 May 17 [14](https://github.com/jorgesolebur/abc/runs/6473124099?check_suite_focus=true#step:4:15):54 ..
-rw-r--r-- 1 root root    128 May 17 14:54 FETCH_HEAD
-rw-r--r-- 1 root root     41 May 17 14:54 HEAD
drwxr-xr-x 2 root root   4096 May [17](https://github.com/jorgesolebur/abc/runs/6473124099?check_suite_focus=true#step:4:18) 14:54 branches
-rw-r--r-- 1 root root    359 May 17 14:54 config
-rw-r--r-- 1 root root     73 May 17 14:54 description
drwxr-xr-x 2 root root   4096 May 17 14:54 hooks
-rw-r--r-- 1 root root 343325 May 17 14:54 index
drwxr-xr-x 2 root root   4096 May 17 14:54 info
drwxr-xr-x 3 root root   4096 May 17 14:54 logs
drwxr-xr-x 4 root root   4096 May 17 14:54 objects
drwxr-xr-x 5 root root   4096 May 17 14:54 refs
-rw-r--r-- 1 root root     41 May 17 14:54 shallow

[petronny]

@jorgesolebur Try git config --global --add safe.directory $(realpath .) before any other git operations.

[dai-mk]

What worked for me was, installing git in the container, fetch-depth: 1 and git config --global --add safe.directory "$GITHUB_WORKSPACE"

[milesvdw]

I'm also having this trouble, it's infuriating. A simple command like
git status fails when run after checkout v2.

Some additional info:

• I'm using a custom built docker image, which is really just ubuntu-latest plus some apt-gets
• My git version (confirmed by running git --version directly before git status) is 2.37.2
• I'm definitely IN a git repo, I can see literally everything from my repo plus meta info like a .git folder full of stuff, including HEAD

[knocte]

My workaround was replacing uses: actions/checkout@v2 with uses: actions/checkout@v1.

[seyuf]

@petronny your suggestion is working for lots of people, myself included. Care to explain why?
BTW i get the same result when i run chown -R root:root instead of git config --global --add safe.directory $(realpath .)
Previously i noticed the .git permission was:
drwxr-xr-x 8 1001 123 4.0K Jan 19 18:17 .git

[seyuf]

Looks like this is the explanation ? #766

[tomdtp]

Just as an update, this error bugged me for quite a while just now. After testing all the suggestions here the only one that helped in the end was running this before my git commands:

git config --global --add safe.directory "$GITHUB_WORKSPACE"

[striezel]

For those of you using container images in their workflows, remember that many smaller container images do not have Git installed by default. So actions/checkout cannot use Git in those cases, unless you install it before the actions/checkout step.

So the basic idea for container workflows should be:

1. Install Git. (apt-get install git / yum install git / apk add git / ...)
2. Inside the container run git config --global --add safe.directory "$GITHUB_WORKSPACE" once before any other git commands are used.
3. Run actions/checkout. If you need the full Git history with tags, etc, also use fetch-depth: 0.
4. Run your git ... commands.

The workflow should look like this (using Alpine Linux container here as an example):

name: Alpine
on: push
jobs:
  alpine:
    runs-on: ubuntu-latest
    container: alpine:latest
    steps:
      # Git is required so that actions/checkout does a proper Git checkout
      # instead of using the GitHub REST API.
      - name: Install Git in container
        run: |
          apk update
          apk add git
          # one time fix to avoid permission problems later on
          git config --global --add safe.directory "$GITHUB_WORKSPACE"
      # Checks-out the repository under $GITHUB_WORKSPACE.
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      # Now the git commands can be used.
      - run: |
          git status
          git log -3
          ...

[rustyhowell]

So for those who are still stuck... I just discovered that the path parameter to the V1 and V3 versions act differently. In V1 with path: foo/bar, the current working directory is foo/bar so the next workflow steps can immediately do git commands.

In V3, the CWD is left at the top level, so you have to cd foo/bar before the and git commands will work.

[knocte]

@rustyhowell but no one has talked about the path: parameter here before? can you explain what you mean, e.g. with a snippet?

[rustyhowell]

I think there are several issues being discussed in this issue. Some people do not have git installed in their runner, some people have older versions of git. My issue was neither of those. My issue was that I expected v3 to behave the same as v1 and they do not.

Below is a snippet that shows that with V3, it clones the source into a subdir foo/bar. Then in the next step, I have to cd foo/bar before I can a git command.

     - uses: actions/checkout@v3
        with:
          path: foo/bar
      - run: |
          cd foo/bar
          git status

But in the old V1, the checkout action leaves you in the path directory

      - uses: actions/checkout@v1
        with:
          path: foo/bar
      - run: |
          #  cd foo/bar   
          git status

This was the issue for me.

[rustyhowell]

My point is, there may be other breaking changes in v2 or v3 that are not well documented. For me, it was the path change.

[seyuf]

This issue feels like the twilight zone ^^.
In fact, before you @rustyhowell everybody here was dealing with the same issue. I.g an permission issue explanation here #766
Strange enough everybody kept copy/pasting the same answer without strangely noticing the previous users stated the same (adding the work dir to the safe.directory). I suspect most of the didn't fully grasp their solution.
Anyways, your issue seems to be a separate one. May be you should create a new issue?
In any case, this issue should defenitely be closed @DannyFriedmanQC ?

[knocte]

@seyuf I disagree with your assessment. Rusty came here probably because he faced the same error message pasted in the title of the github issue. The fact that some people have already stated the same workaround many times and that this workaround may have worked for the original reporter doesn't mean that this github issue should be closed, because it is just a workaround, and because that workaround may not be helpful to other people that may be facing the same error message (even if the issue is not the same one as the original reporter's issue, albeit receiving same error).

[seyuf]

@knocte I suggested closing the issue as i m afraid this will never be fixed. As the range it is covering is too wide.
In my case, for example, the permissions were wrong due to a misconfiguration of our github runner in one instance. And in the other, a code in the action we was using was changing the permissions of the files leading to the error. So clearly this issue, in most cases, is beyond the reach of the checkout action.
Nonetheless, i do see your point. You seem to believe that there will be a fix for this. I just don't see how. But may be im in the wrong. It has been 4 years now...