GitHub Actions checkout fails because of an unexpected gitlink/submodule without .gitmodules

[the-par3a]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

other

Discussion Details

Hello GitHub Community,

I'm experiencing an unusual issue with a repository where GitHub appears to treat a directory as a Git submodule/gitlink, even though I did not intentionally configure it as a submodule.

Repository:
the-par3a/ticketing-v2

The repository contains an entry named:

ticketing-v2

On GitHub, this entry is displayed with the blue folder/submodule-style icon rather than as a normal directory.(like this )

I checked the repository tree through GitHub's API and found:

"path": "ticketing-v2",
"mode": "160000",
"type": "commit",
"sha": "9be1252a062de826a9f795d9a9f28a553f3a4f2a"

GitHub's contents API also reports:

"type": "submodule"

However, there is no .gitmodules file in the repository.

The submodule information also appears incomplete because GitHub reports:

"submodule_git_url": null

This causes GitHub Actions checkout to fail during post-job cleanup with:

fatal: No url found for submodule path 'ticketing-v2' in .gitmodules

The relevant part of the Actions log is:

The process '/usr/bin/git' failed with exit code 128

fatal: No url found for submodule path 'ticketing-v2' in .gitmodules

What makes this unusual is that I did not intentionally configure ticketing-v2 as a submodule, and there is currently no .gitmodules file in the repository.

I would like to understand how this gitlink was created and whether GitHub can help determine its origin or confirm whether this is a stale/broken submodule reference.

For now, I have intentionally not modified or removed the entry because I would first like to understand exactly what happened.

Any guidance on safely diagnosing this situation would be appreciated.

Thank you!

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[buildwithfiroz]

This isn't a GitHub server-side bug — it's standard Git behavior, and it's a very common accident. Here's what's happening:

Mode 160000 = "gitlink" is created automatically whenever you git add a directory that itself contains a .git folder (i.e., is its own Git repository) — even if you never ran git submodule add and never created a .gitmodules file.

Git doesn't check whether you intended a submodule. If it sees a nested .git directory inside the path being added, it silently records a commit-reference (gitlink) pointing at whatever HEAD that nested repo was on, instead of recursing into it and adding the actual files. This commonly happens when:

• A full repo (including its .git folder) gets cloned or copied into a subdirectory of another repo, and git add . is run from the parent afterward.
• A CI step, template scaffold, degit/npx create-* tool, or IDE "import project" action leaves a stray .git folder behind inside a subfolder before it gets committed.
• .gitignore doesn't exclude **/.git, so the nested repo's git metadata gets swept into the index by accident.

Since no .gitmodules entry was ever written (that file is only created by git submodule add), Git ends up with a gitlink in the tree with no corresponding URL to resolve it against — hence submodule_git_url: null in the API, and hence the checkout failure. actions/checkout's post-job cleanup step sees the gitlink and tries to run submodule commands against it, which fail because there's nothing in .gitmodules telling it where the submodule came from.

How to confirm the origin

Before changing anything, find the commit that introduced it:

​bash git log --diff-filter=A --follow -- ticketing-v2 ​

Then inspect that commit:

​bash git show <commit-sha> -- ticketing-v2 ​

You should see it was added with mode 160000 in that diff, confirming it was committed as a gitlink from the start (most likely because a .git folder was present locally at the time of git add).

How to fix it

​```bash

1. Remove the gitlink from git's index (keeps your local files intact)

git rm --cached ticketing-v2

2. If a nested .git folder still exists locally, remove it

so the directory stops behaving like its own repo

rm -rf ticketing-v2/.git

3. Re-add the directory normally — this time git will add

the actual files instead of a commit reference

git add ticketing-v2

4. Commit and push

git commit -m "Fix: replace stray submodule gitlink with normal directory"
git push
​```

After this, the blue submodule icon should disappear on GitHub, the API will report "type": "dir" instead of "submodule", and actions/checkout should stop failing since there's no gitlink left for it to try to resolve.

Short-term CI workaround (if you can't fix the history right away)

​```yaml

• uses: actions/checkout@v4
  with:
  submodules: false
  ​```

Note this only helps if the gitlink itself isn't otherwise breaking the checkout step — worth testing first. The real fix is removing the gitlink from the tree as shown above; submodules: false doesn't guarantee the cleanup step won't still trip over an existing gitlink in every case.