I think that's likely what the contributors wanted too. This issue was opened in December of 2022 and it seems like reactions to it were mostly positive.
Forgejo codebase includes basic support for go-git, a Go package distributed under a permissive license that can be used in place of Git
And the fact that it only needs an external binary that understands git commands tells me that it's not technically tied to "Git proper" as much as they want us to believe.
You missed out this fairly important bit re go-git:
it is not supported or packaged because it is not fully compatible and could corrupt Git repositories.
As far as being tied to git proper, that's because there is no drop-in alternative implementation that implements all the functionality that you need to run a Git server. Right now, Git proper is your only option. That might change as gitoxide matures, but that could take years.
Either way, even if they just stated that they just like the GPL, and want it to apply to their contributions towards federation and other improvements, I think that's a reasonable decision as long as their primary contributors agree with it too. I don't think a fork seems necessary unless the contributors want it to remain permissively licensed.
I did see that, I just didn't feel that it was relevant to my point
there is no drop-in alternative
My point was that there could be (and the GPL even wants there to be). Also "Both Forgejo and Git must be used together" could be construed as Git itself requiring Forgejo, which isn't true either.
The fact that forgejo only calls an external git binary is what makes such tools compatible with non-GPL software as well... you just have to be able to substitute the binary for something else, it doesn't matter if that "something else" exists yet or not.
Maybe we just differ on our definitions of "requiring Git".
Isn't GitTea still under the MIT? I just don't see the purpose for switching licenses, I didn't think it was significantly different. It really doesn't matter to me though, I didn't plan on creating a custom version anyway.
If you had read the very short blog post you would have learned that they wanted to merge in some GPL licensed code contributions. This sort of behavior is exactly what the GPL copyleft language is intended to encourage.
I had read the discussion in the past and saw they already had GPL related dependencies they had pulled into the repository. I don't know the full history or the contributors project goals. I usually don't find GPL code hard to avoid in normal MIT projects already separated from the GPL, but I can't state an opinion because I haven't tried to understand the background. This is to say, I don't find it completely convincing, and view it partially related to the contributors just liking the GPL.
I wouldn't personally make this choice because the project competes with an MIT licensed version. As an example, one of their goals is federation which might bring companies which realize they don't need GitHub to promote their projects or collaborate. If their competition does the same, those companies might be more likely to choose the permissively licensed version instead. Though, this is a hypothetical example, and I think I'm just negatively biased against the GPL.