Error when pushing with submodule.recurse=true "Gitea: Internal error" #11006

New Issue

GiteaMirror · 2025-11-02T09:24:42-06:00

GiteaMirror commented

2025-11-02 09:24:42 -06:00

Originally created by @nvx on GitHub (Jun 10, 2023).

Description

Steps to reproduce (can reproduce on try.gitea.io, substitute the remote url with an empty repo you have push access to)

$ git config --global submodule.recurse true
$ git clone https://github.com/flipperdevices/flipperzero-firmware.git
<snip>
$ git remote add try git@try.gitea.io:nvx/flipperzero-firmware.git
$ git push try dev
fatal: remote 'try' not configured
fatal: process for submodule 'assets/protobuf' failed
fatal: the remote end hung up unexpectedly
Gitea: Failed to execute git command

Pushing to another GitHub remote works fine. Nothing out of the ordinary appears in the logs, no errors/etc.

Unsetting the submodule.recurse option allows the repo to be pushed as expected.

My server shows "Gitea: Internal error" instead of "Gitea: Failed to execute git command" though. Not sure if this is a Gitea version or Git version difference (I'm on gitea/gitea:1.19.3 docker image with whatever version of Git/etc is bundled in that image).

Gitea Version

1.19.3, but also on try which is 1.20.0+rc0-20-gfeb38da25

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

My server is Docker, but reproducible on the demo site too

Database

PostgreSQL

Originally created by @nvx on GitHub (Jun 10, 2023). ### Description Steps to reproduce (can reproduce on try.gitea.io, substitute the remote url with an empty repo you have push access to) ``` $ git config --global submodule.recurse true $ git clone https://github.com/flipperdevices/flipperzero-firmware.git <snip> $ git remote add try git@try.gitea.io:nvx/flipperzero-firmware.git $ git push try dev fatal: remote 'try' not configured fatal: process for submodule 'assets/protobuf' failed fatal: the remote end hung up unexpectedly Gitea: Failed to execute git command ``` Pushing to another GitHub remote works fine. Nothing out of the ordinary appears in the logs, no errors/etc. Unsetting the submodule.recurse option allows the repo to be pushed as expected. My server shows "Gitea: Internal error" instead of "Gitea: Failed to execute git command" though. Not sure if this is a Gitea version or Git version difference (I'm on gitea/gitea:1.19.3 docker image with whatever version of Git/etc is bundled in that image). ### Gitea Version 1.19.3, but also on try which is 1.20.0+rc0-20-gfeb38da25 ### Can you reproduce the bug on the Gitea demo site? Yes ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System _No response_ ### How are you running Gitea? My server is Docker, but reproducible on the demo site too ### Database PostgreSQL

GiteaMirror added the issue/confirmed type/bug labels 2025-11-02 09:24:42 -06:00

GiteaMirror commented

2025-11-02 09:24:43 -06:00

@wxiaoguang commented on GitHub (Jun 12, 2023):

Added "confirmed" label.

To answer:

My server shows "Gitea: Internal error" instead of "Gitea: Failed to execute git command" though. Not sure if this is a Gitea version or Git version difference

Because Gitea 1.20 optimized the feedback error message. It's more meaningful than "Internal Error" now. We can see that the problem is caused by git command error .... well, it needs some time do debug/fix (ps: I am not working on it now, only share some ideas, feel free to pick it)

@wxiaoguang commented on GitHub (Jun 12, 2023): Added "confirmed" label. To answer: > My server shows "Gitea: Internal error" instead of "Gitea: Failed to execute git command" though. Not sure if this is a Gitea version or Git version difference Because Gitea 1.20 optimized the feedback error message. It's more meaningful than "Internal Error" now. We can see that the problem is caused by git command error .... well, it needs some time do debug/fix (ps: I am not working on it now, only share some ideas, feel free to pick it)

GiteaMirror commented

2025-11-02 09:24:44 -06:00

@nvx commented on GitHub (Jun 13, 2023):

My server shows "Gitea: Internal error" instead of "Gitea: Failed to execute git command" though. Not sure if this is a Gitea version or Git version difference

Because Gitea 1.20 optimized the feedback error message. It's more meaningful than "Internal Error" now. We can see that the problem is caused by git command error

I expected as much. I must admit it was rather confusing seeing just "Internal Error" and nothing in the logs on 1.19, at least 1.20 gives a hint where the problem is (maybe it also shows more in the server logs, I haven't tried running 1.20 yet locally).

Cheers for the confirmation. At least I figured out a workaround so it's not really a showstopper, but hopefully saves some confusion for the next guy at the very least. :D

@nvx commented on GitHub (Jun 13, 2023): > > My server shows "Gitea: Internal error" instead of "Gitea: Failed to execute git command" though. Not sure if this is a Gitea version or Git version difference > > Because Gitea 1.20 optimized the feedback error message. It's more meaningful than "Internal Error" now. We can see that the problem is caused by git command error I expected as much. I must admit it was rather confusing seeing just "Internal Error" and nothing in the logs on 1.19, at least 1.20 gives a hint where the problem is (maybe it also shows more in the server logs, I haven't tried running 1.20 yet locally). Cheers for the confirmation. At least I figured out a workaround so it's not really a showstopper, but hopefully saves some confusion for the next guy at the very least. :D

GiteaMirror commented

2025-11-02 09:24:44 -06:00

@Nevada317 commented on GitHub (Apr 15, 2025):

I've got the same error text today while using vanilla git 2.49.0:

fatal: remote 'e38' not configured
fatal: process for submodule '...' failed

Error was solved when i have pushed submodule manually and only then tried to push main project again.

I think this error arises when you try to push repo with submodule revision not sent to server, but that seems rather strange.

Here is format of my .git/config inside repository:

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[remote "e38"]
    url = ssh://user@e38.example.org:port/srv/projectname
    fetch = +refs/heads/*:refs/remotes/e38/*
[submodule]
    recurse = true
[submodule "..."]
    url = ssh://user@e38.example.org:port/srv/...
    active = true
... other submodules follow ...

Possible workaround: set submodule.recurse = false

@Nevada317 commented on GitHub (Apr 15, 2025): I've got the same error text today while using vanilla git 2.49.0: ``` fatal: remote 'e38' not configured fatal: process for submodule '...' failed ``` Error was solved when i have pushed submodule manually and only then tried to push main project again. I think this error arises when you try to push repo with submodule revision not sent to server, but that seems rather strange. Here is format of my `.git/config` inside repository: ``` [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote "e38"] url = ssh://user@e38.example.org:port/srv/projectname fetch = +refs/heads/*:refs/remotes/e38/* [submodule] recurse = true [submodule "..."] url = ssh://user@e38.example.org:port/srv/... active = true ... other submodules follow ... ``` Possible workaround: set `submodule.recurse = false`

GiteaMirror commented

2025-11-02 09:24:44 -06:00

@Nevada317 commented on GitHub (Apr 18, 2025):

I have found real key to the issue.

I had different remote names for main project and submodules.
Main project had remote named e38, while the submodule had only origin. Easiest way to solve was:

Open .git/modules/modulename/config file
Find [remote "origin"] line
Rename it to desired remote (same one, as in .git/config)
Also, near that line correct fetch = +refs/heads/*:refs/remotes/origin/* line, changing /origin/ to correct value.

I think that bug should be escalated to git, as origin is default remote name, that should be pulled from main project for submodules, instead of hardcoded value.

@Nevada317 commented on GitHub (Apr 18, 2025): I have found real key to the issue. I had different remote names for main project and submodules. Main project had remote named `e38`, while the submodule had only `origin`. Easiest way to solve was: * Open `.git/modules/modulename/config` file * Find `[remote "origin"]` line * Rename it to desired remote (same one, as in `.git/config`) * Also, near that line correct `fetch = +refs/heads/*:refs/remotes/origin/*` line, changing `/origin/` to correct value. I think that bug should be escalated to `git`, as `origin` is default remote name, that should be pulled from main project for submodules, instead of hardcoded value.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#11006