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

[nvx]

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

[wxiaoguang]

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)

[nvx]

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

[Nevada317]

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]

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.