|
> This seems like an extremely common problem in computing. I agree—I see it all over the place. It's what you get for a UI by default, if you don't take any extra measures to seek an effective design: you just expose program internals. I think the situation with git is slightly different from that all too common, naive pattern, though. The best comparison I can make is to graphics APIs like OpenGL (or even better, Vulcan), which are there in large as a means of giving access to graphics hardware, very low-level and a horrible impedance mismatch for actually describing moving images. However, they are necessary because the variety of things people might want to do with a graphics card is so vast, that 'nicer' abstractions will always also be restrictions on capabilities. So, you get OpenGL/Vulcan and rather than using it directly to build applications, it's the basis for building other graphics libraries which actually have good usability. (But also like git, there are many cases where people just need to use the low-level APIs directly, despite poor usability.) Git seems to be addressing a similar issue in that any abstraction over the internal core data structures ends up limiting the vast spectrum of potential use cases, so it makes the compromise of providing (relatively) un-abstracted access to the program's core data structures, which maximizes use-cases covered, and sacrifices usability. But, the generality it provides leaves open the possibility of building higher-level abstractions on top of it... I know a bunch of these exist in various forms, CLI and GUI, and for me anyway, none that I'm aware of cover everything I need to do with git—but I believe such an application could be built and the community would stabilize on using it for 90% of cases instead. As far as visualization of its data structures goes, I see it fitting in as training wheels essentially: it would be an effective way of teaching people how the program works by allowing them to see the direct impact of particular git commands on the git data structures. Eventually you stop using it, except for troubleshooting really weird/obscure situations, as you mention. (More generally, I could see open source projects offering a flag so that their core data structures are visualized or not as a means of more effectively/enjoyably teaching new developers how data moves around in the app at a high level.) |
The beauty of being able to use an abstraction on top of git is that it doesn't need to cover everything you do. You can use a GUI or a couple simple aliases or scripts for daily driving and then move to the CLI for surgery; a good GUI will have a CLI pane or a button to open a CLI in the right directory.
Even for simply committing, it's nice to have the GUI visualization as an easy sanity check that you haven't accidentally added tons of files, or as an easy way to browse your changes before committing.
Stabilizing on git itself is good enough, there's no need for everyone to use the same abstraction on top of it. The only reason there's so much focus on the CLI is because it's the default, and because power users keep convincing newbies that you're not cool if you don't use it.