Thomas Koch <thomas@xxxxxxx> writes: > I'm a software engineer now with an education as a high school teacher. From a > theoretical point of view it's preferable to avoid any abstraction done by a > GUI and use commandline Git. Only gitk is useful to have a visual _feedback_ > of the actions done on the commandline. > > But also from experience I can tell that without exception everybody whom I > teached Git understood it only after being introduced to the basic concepts of > Git and how to inspect and operate them on the commandline. Others told me > from similar experiences. > ... > My collegues meanwhile dumped their graphical Git tool because they learned > that they have better control over Git when using it from the commandline. Interesting. I think any UI needs to fill three objectives: - make common tasks easy; - make complex tasks possible; and - help users build the right mental model. As a tool from Linus school, we started from the second and the third point. Our UI (i.e. CLI) has long been notorious for lacking in the first department, and we have worked long and hard to improve on that front. While there are more work needed for CLI, your observation, and a similar experience by Noufal in the thread, hints me that the available GUI tools have concentrated primarily on the first point but are still lacking in the rest. Perhaps I am being naïve, but I would expect that a GUI is a much better vehicle to help users build the right mental model. Unlike CLI, it has a canvas to draw pretty pictures and present the users what the user is really doing after all. And I am sure GUI people will eventually realize that potential in the tools they are building, and the world will become a better place for both GUI and CLI users ;-). I found "ungit" an interesting experiment that goes into that direction. Being forever hopeful... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html