Potential duplicates:

It's worth mentioning that the older version that works fine 2.48.05 pops this up often. 2.48.05 doesn't crash no matter what is selected off this pop up.

@gerhardol do you think you can look at this?

I cannot reproduce, I tried with single submodule lost, all lost or no submodules at all.
Same for latest release and latest master (few chances in this area.)
Please describe a repo to reproduce with.

For the popup to prompt to update submodules at checkout, this is not changed from 2.x. You may control the popup in settings:

I was able to resolve this issue by removing the following from my .gitmodules file. The directories didn't exist on my machine, and the branch wasn't local. I'm not sure if having both would've prevented the startup crash or not. For me, I'm on a large team and everyone is using GE 2.48.05 due to the crash. Hopefully this helps.

[submodule "C:/Project/x/y"]
path = C:/Project/x/y
url = C:/Project/x/y
branch = release/201705

Asking @RussKie or @gerhardol to reopen based on my new findings.

I certainly can. I just thought being this was a real-world example of a breaking change in GE beyond 2.48.05 that it would want to be addressed somehow to handle it more gracefully. It wasn't obvious to me what the issue was, and outright prevented using GE. If it's classified user-error, then accept my apologies.

I was able to resolve this issue by removing the following from my .gitmodules file. The directories didn't exist on my machine, and the branch wasn't local. I'm not sure if having both would've prevented the startup crash or not. For me, I'm on a large team and everyone is using GE 2.48.05 due to the crash. Hopefully this helps.

2.48 is not even the latest 2.x release, any specific reason to stay on that release?
(I assume you are using Mono.)
There are no 2.x releases planned by the core team, no Mono users (a reason to why it was impossible to maintain Mono), but contributions could be merged. I doubt this problem wold be considered important enough though.

I'm on 3.5.4.12724. What I'm saying is that my team has been on 2.48.05 for years now due to this startup crash. This is what I had to do to resolve it. Neither git CLI or SourceTree had a problem with the repo on any of their releases.

@vbjay Got you now. Yes, I did try yes on that menu but it didn't change the outcome (menu presenting on 2.48.05, or crashing on any newer release).

If I knew what the issue was exactly I'd be happy to do that but I don't know how to reproduce it other than what I've provided here and I can't take the risk of cutting down our production repo and passing that along (in case I make a mistake and leave something, I'd be fired and then sued).

I'm good on my side, just like the software and wanted to help fix whatever was going on in case other users run into it, and promptly uninstall. But if it's not enough information, I understand and it's really up to the developers. We can leave this closed out. Thanks for checking in on my update!

For me, I'm on a large team and everyone is using GE 2.48.05 due to the crash.

@mwkinney If the issue is fixed, will your company (with such a large team) do a good donation to the GitExtensions project for allowing it to upgrade to the last version with tons of great features that will improve the whole team their day to day workflow and efficiency? 😁

@pmiossec If it were fixed I'd certainly ask. I'm in charge of nothing though. I pushed the .gitmodules change to our repo so everyone can now after years update. It's a multilayered contractor situation and I'm on the bottom of it all. But the larger partner on top is a very large corporation out of California that everyone knows of.

I was really trying to help the project with a bug report and other users past/present/future that ran into the same issue. Like I said, SourceTree handled it fine, GE 2.x worked fine. For me, if this is software that I were in charge of, I'd want whatever the issue was, handled more gracefully. But I'm sure most of these type of reports (especially when you can't easily reproduce the issue, though I assume many here already know the issue), aren't easily reproducible.

I'm mostly a web guy but I'm capable of digging in and submitting a PR. I don't do that with projects because you can do the work and zero guarantee it's accepted. Or, projects reject it and end up doing it themselves.

I just thought I'd spend a few minutes reporting it, because I know that I would want to know. I appreciate this team and the software created.

I was just asking because I have a fix 🤣 I will create a PR tomorrow.

I was really trying to help the project with a bug report and other users past/present/future that ran into the same issue.

What you did was good and thanks for the help. That's just that like you could see, your issue did had a lot of traction because it is highly possible that you're nearly the only one having this problem.

And solving this type of issue is really time consuming and most of the time end up being something badly configured or whatever else specific to the computer of the user. This is the type of bugs where the one encountering it is the best placed to fix it or at least debug it.
So it is comprehensible that the few hours that an opensource developer has are spent on something bringing more added value...