> First of all, because git is a CLI application you can easily build a GUI for it,
Actually you can't, because Git has features like "pre-commit hooks" and it's literally impossible to translate the output/messages of those into reasonable form for a GUI to consume (since it's just freeform CLI output text). The best you can do is simply echo them back to the user in a stupid text dialog box. You'll notice all Git GUIs either don't support pre-commit hooks at all (always commit with them set to disabled), or display the output of them using the lazy text dialog box method.
The other limitation, of course, is that since Git has no library, it's impossible for a GUI to be based on Git without it actually using Git CLI commands in the background. Which means if the Git CLI changes its commands, suddenly its broken all GUIs built off of it. (GUI clients generally "solve" this problem by shipping their own Git binary and using it exclusively, even if a newer one is on the same system.)
(It's funny that you mention WinForms. What Git does with its CLI commands is pretty much exactly equivalent to a WinForms app with business logic in the event handlers. Except where any WinForms developer would say, "why are you mixing up the UI and the program logic? That's a terrible idea!" apparently Git developers think it's great and double-down.)
It's impossible to build a truly quality GUI without the product being designed with that in mind from the start. Git wasn't. And there was simply no excuse for that in 2005.
> You can't do the reverse,
The correct way of writing an application is to put all the functionality into a library, then keeping your user interfaces separate from that library. So while you're right that you can't do the reverse (build a quality CLI from a GUI application), if the developers of Git had done their job correctly, you wouldn't have to. Git would have a core library that anybody could build any kind of user interface from.
> Second, what "physical limitations" put people into a position where they can code but they can't use a CLI?
Dyslexia. I can manage in an IDE with a large dependence on auto-complete, but I can't do a CLI.
Since I grew up on Macs and it's only relatively recently that crud like Git has been seeping into the Windows development scene, this had never been a limitation for me in the past. Worse than being user-hostile, Git makes me feel disabled in a way no other program has.
> Multimedia artists are among the people who are most resistant to ever switch tools due to how much they have mentally invested into the complexities of their go-to application. Your example is far from good.
I'm sorry my examples do not meet your exacting standards.
Ok...
> First of all, because git is a CLI application you can easily build a GUI for it,
Actually you can't, because Git has features like "pre-commit hooks" and it's literally impossible to translate the output/messages of those into reasonable form for a GUI to consume (since it's just freeform CLI output text). The best you can do is simply echo them back to the user in a stupid text dialog box. You'll notice all Git GUIs either don't support pre-commit hooks at all (always commit with them set to disabled), or display the output of them using the lazy text dialog box method.
The other limitation, of course, is that since Git has no library, it's impossible for a GUI to be based on Git without it actually using Git CLI commands in the background. Which means if the Git CLI changes its commands, suddenly its broken all GUIs built off of it. (GUI clients generally "solve" this problem by shipping their own Git binary and using it exclusively, even if a newer one is on the same system.)
(It's funny that you mention WinForms. What Git does with its CLI commands is pretty much exactly equivalent to a WinForms app with business logic in the event handlers. Except where any WinForms developer would say, "why are you mixing up the UI and the program logic? That's a terrible idea!" apparently Git developers think it's great and double-down.)
It's impossible to build a truly quality GUI without the product being designed with that in mind from the start. Git wasn't. And there was simply no excuse for that in 2005.
> You can't do the reverse,
The correct way of writing an application is to put all the functionality into a library, then keeping your user interfaces separate from that library. So while you're right that you can't do the reverse (build a quality CLI from a GUI application), if the developers of Git had done their job correctly, you wouldn't have to. Git would have a core library that anybody could build any kind of user interface from.
> Second, what "physical limitations" put people into a position where they can code but they can't use a CLI?
Dyslexia. I can manage in an IDE with a large dependence on auto-complete, but I can't do a CLI.
Since I grew up on Macs and it's only relatively recently that crud like Git has been seeping into the Windows development scene, this had never been a limitation for me in the past. Worse than being user-hostile, Git makes me feel disabled in a way no other program has.
> Multimedia artists are among the people who are most resistant to ever switch tools due to how much they have mentally invested into the complexities of their go-to application. Your example is far from good.
I'm sorry my examples do not meet your exacting standards.