git-istage: Launching console text editor hangs console.

In case anyone cares what the fix was:

• In .NET you can generally launch a CLI from a CLI process just fine; the new process will use the same terminal, that is, it will read from its input and write to its output.
• However, this means that the process shouldn’t be launched with redirecting output if you intend for it to be visible… duh. In my case, I generally do that when launching Git in order to capture its error log. For commands that Git will spawn the editor for that’s obviously not a good idea.
• Lastly, when using alternative screen buffers you want to swap back to the main screen buffer too.

I will try to explain, but first, let me ask you this: what is so crucial that this tool gains from using latest-and-greatest vs LTS that trumps the convenience of availability and ease of install?

I will admit that this is somewhat selfish on my end. I work on the .NET team, so I’m basically living on cutting edge and I want to dogfood our features. In the context of this tool this would usually involve library- or language features. Most recent example: C# 11’s raw string literals.

My background is library development; for libraries it usually makes sense to target an older version of .NET in order to have more reach. As a library dev, it’s common to multi-target, i.e. build for multiple version of .NET in order to support the latest features while not sacrificing reach. This comes, of course, with some amount of complexity for testing and building.

For app development this kind of thinking feels overly complicated. It makes more sense to me to say that this tool requires the latest version of .NET which anyone can install. Well, until recently I naively assumed that when we release it’s also available for most Linux distros, which I just learned isn’t the case. I should add that I’m mostly on Windows and Mac and for those platforms we (Microsoft) release the builds for.

I guess I’ll need to think about this and reconsider.

Would you mind filing a separate issue, asking to make this tool only use .NET LTS releases?

I really would like to understand why.

I will try to explain, but first, let me ask you this: what is so crucial that this tool gains from using latest-and-greatest vs LTS that trumps the convenience of availability and ease of install?

Reasons:

• This tool should “just work”. What should have been a 15 min shell command spree turned into a multi-day affair.
• Lots and lots of developers working on enterprise software shun bleeding-edge upgrades. I, for once, will never use net7, just like I completely ignored net5. I migrated my stuff to net6 from netcore3.1. This net7 sdk will just needlessly consume 300MB of VM disk space.
• Stability is important just as implicit understanding that a dependency is likely available for the system you want to use this on. Your move to net5 bit me once already when I was on VS2019. There was no need to upgrade from netcore3.1 just like there’s no need to upgrade to net7 now.
• Visual Studio 2022 update 17.4 bit me again by uninstalling net6 sdk completely, thank you very much. Now I have to go to all my build boxes and reinstall net6 sdk manually because my global.json pins it so.
• There was a time when Razor pages targeting netcore3.1 would generate bad code when built with net6 sdk … I pin my sdks now.
• many, many more … I would rather not go into them, at the risk of this sounding like an “old man yelling at cloud” … but MS over the last few years transitioned into a company that half-a$$es things.

@yurikus, a new version (v0.3.93) was being published to NuGet. It’ll probably take 30-60 min before it will show up though.