Git blame delivers different results in Gitlab CI than on local machine - bash

Question

I've created a small shell script that uses the output of git blame to generate some reports. This works great on my local machine. But then I wanted to integrate the shell script in our gitlab ci/cd pipeline and for some reason when I run git blame on gitlab, all lines are attributed to me and the latest commit.
This is what I put in my pipeline file to debug this issue:
run-git-blame:
stage: mystage
image: alpine
before_script:
- apk add bash git gawk
- git status
- git log
script:
- git blame HEAD -- somefile.txt
When I run git blame HEAD -- somefile.txt locally I get:
4588eb70a0b (DXXXXXXX 2019-05-07 15:35:22 +0200 1) abc=123
4588eb70a0b (DXXXXXXX 2019-05-07 15:35:22 +0200 2) def=456
4588eb70a0b (DXXXXXXX 2019-05-07 15:35:22 +0200 3) ghi=789
4588eb70a0b (DXXXXXXX 2019-05-07 15:35:22 +0200 4) jkl=abc
4588eb70a0b (DXXXXXXX 2019-05-07 15:35:22 +0200 5) mno=def
[...]
However the gitlab ci output looks like this:
^5e95b8e5 (Sebastian Gellweiler 2020-09-24 09:32:54 +0200 1) abc=123
^5e95b8e5 (Sebastian Gellweiler 2020-09-24 09:32:54 +0200 2) def=456
^5e95b8e5 (Sebastian Gellweiler 2020-09-24 09:32:54 +0200 3) ghi=789
^5e95b8e5 (Sebastian Gellweiler 2020-09-24 09:32:54 +0200 4) jkl=abc
^5e95b8e5 (Sebastian Gellweiler 2020-09-24 09:32:54 +0200 5) mno=def
[...]
Bu I have definitevly not touched the file being inspected.
The git status command outputs the following on the server:
HEAD detached at 5e95b8e5
nothing to commit, working tree clean
And this looks fine, as 5e95b8e5 is the hash of the latest commit.
What also puzzles me is the output of git log on gitlab because it only shows one commit and no history:
commit 5e95b8e5efcfd155d4248f4849b848e9f1580a20
Author: Sebastian Gellweiler <sebastian.gellweiler#dm.de>
Date: Thu Sep 24 09:32:54 2020 +0200
...
This is what the history on my local machine looks like:
commit 5e95b8e5efcfd155d4248f4849b848e9f1580a20 (HEAD -> feature/XXX)
Author: Sebastian Gellweiler <sebastian.gellweiler#example.org>
Date: Thu Sep 24 09:32:54 2020 +0200
...
commit bc689804f87d906e1b2435249fc1aaaf32e49b20
Author: Sebastian Gellweiler <sebastian.gellweiler#dm.de>
Date: Wed Sep 23 18:40:18 2020 +0200
XXX
commit 9d6fa2336aee0938aef0bd78563b6f12dee5934f (master)
Merge: 90ef282515 3eabec88c2
Author: XXXX <XXX#example.org>
Date: Thu Sep 17 08:31:20 2020 +0000
XYZ
[...]
As you can see the top commit hash is the same on my local machine and on the remote.
I'm stuck here. Anybody has an explanation for this discrepancy?

Answer 1

I think you have GitLab configured to make a shallow clone that has depth 1. Since it has only one commit, every file in the repository is the way it is due to the (single, one) commit that is in the repository, so that's the hash ID it produces.
In particular, this notation:
^5e95b8e5
indicates that Git knows there is something before 5e95b8e5, but not what it is, which in this case is the mark of a shallow repository. (Technically it's a boundary mark and you'd see it on some other commit if you had used a range expression, such as abc1def..HEAD. You can use the -b option, or some configuration items, to alter how these are shown.)

Answer 2

Git commits only connect to their parents, Git can only go through history backwards. If you have a commit checked out that's older than 5e95b8e5 you will not see it in git blame nor git log.
Alternatively, your local repo is out of datee and you need to git pull.