"Can't find HEAD commit for this branch" in CI Pipelines

Every entry in “CI Pipelines” shows “Can’t find HEAD commit for this branch” under the “Commit” column instead of the commit message. If I view the same commits in Repository -> Commits they show up fine.

This is a fairly new repo with only a single branch (master) and 19 commits.

Welcome to the forum @nathanjovin! :tada:

That is one I haven’t seen before. If you check out the repository locally, what does the output of cat .git/HEAD return? Assuming it is ``, then does the command cat .git/refs/remotes/origin/master return the same hash that you’d expect? In this screenshot, that is 43612eab.

Also, is it possible you committed those with either no commit message or with unsafe characters, is blank or starts with a few carriage returns? What is the output of git reflog or git log --oneline? I’m wondering if there’s just something about those commit messages that GitLab doesn’t like.

Hope that helps uncover this one!

Thanks for the response @olearycrew.

cat .git/HEAD returns ref: refs/heads/master and .git/refs/remotes/origin/master does return the hash I expect, edb097e013adf017b94da40903b1cf1167f11152, which matches with the most recent one shown on the CI Pipelines page, even though that page shows Can't find HEAD commit for this branch under that hash.

All of my commits have messages with no special characters, usually simple single-sentence descriptions. The top line from git reflog reads edb097e (HEAD -> master, origin/master) HEAD@{0}: commit: Fix token refresh, add debug info so that hash matches and it shows my latest commit message. git log shows the same information formatted differently.

Wow, sorry @nathanjovin but that’s everything I would have expected in a “normal” repo. I’m not sure what to try next, but if it was me I’d try uploading it to a different GitLab project by adding a second remote just to see if something might be “wrong” with how the repo was created on GitLab.

@olearycrew I just tried creating a new private repo (nathanjovin/gitlab-support-test), added it as a remote (git remote add support-test git@gitlab.com:nathanjovin/gitlab-support-test.git), pushed it up (git push support-test) and I see the exact same problem in the new repo: the pipline CI list reads “Can’t find HEAD commit for this branch”

I’ve encountered this too. I think this occurs concistently when I (using the Gitkraken client) do not include a commit message, but a commit “body”…

There’s two fields, one for the commit message (title) and commit message. Typing in the body allows you to perform the commit, with no title. In git, this all works, but it seems Gitlab doesn’t work with it.

2 Likes

@olearycrew hey - In my case, there is a distinct lack of a title on the offending commit. I’m not sure how to reproduce it exactly, it’s not consistent across repositories.

In this repo, the commit has no title, unlike the next one.

… but in this repo, the “same” message yields a title. This second repo does not experience the error described.

In these two, the messages are identical, but gitlab does not consider one of them to have a title. This lack of a title results in f.ex. this in the commit view (no title = no clickable link):

I’m not sure how to determine the difference in these commit messages… Both git cli and gitkraken seem to show them to be identical, but I find it likely that there might be a character or something in the offending commit that borks Gitlab.

Yes, LordMike, you are right! I was also wondering why there is the message. But when adding a commit message (instead only the body) it looks nice!! :slight_smile:

Thanks for the hint

For me this happens to commits created with GitKraken where only a summary or description was provided, not both.

I extracted the commit message (git log --format=%B):

Only summary:
image

Only description:
image

Then I tried setting the description to a white space, which created this:
image

The latter one displayed correctly in GitLab.

For comparison, a commit created with git commit -m 'test' results in this:
image

So in either case there are 3 LFs involved and one of the two strings (title, description) is probably parsed as empty.
Interestingly, “test” from the first picture is only shown after clicking on the three dots as well, even though the text is at the start of the message.