Thomas Koch <tho...@koch.ro> writes:
> I'm a software engineer now with an education as a high school teacher. From
> 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
> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html