From: Junio C Hamano <gitster@pobox•com>
To: Thomas Koch <thomas@koch•ro>
Cc: Matthieu Moy <Matthieu.Moy@grenoble-inp•fr>,
git <git@vger•kernel.org>,
Noufal Ibrahim KV <noufal@nibrahim•net.in>,
Andreas Krey <a.krey@gmx•de>
Subject: Re: Command-line git Vs IDE+plugin?
Date: Tue, 19 Nov 2013 08:53:33 -0800 [thread overview]
Message-ID: <xmqqbo1g9vua.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <201311191336.31000.thomas@koch.ro> (Thomas Koch's message of "Tue, 19 Nov 2013 13:36:30 +0100")
Thomas Koch <thomas@koch•ro> 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...
next prev parent reply other threads:[~2013-11-19 16:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-18 17:11 Command-line git Vs IDE+plugin? Matthieu Moy
2013-11-18 17:42 ` Philippe Vaucher
2013-11-18 18:46 ` Matthieu Moy
2013-11-19 9:53 ` Konstantin Khomoutov
2013-11-18 17:47 ` Andreas Krey
2013-11-19 12:36 ` Thomas Koch
2013-11-19 16:53 ` Junio C Hamano [this message]
2013-11-19 17:20 ` Matthieu Moy
2013-12-04 9:56 ` Gauthier Östervall
2013-11-19 16:55 ` Keshav Kini
2013-11-19 12:45 ` Noufal Ibrahim KV
2013-12-04 11:10 ` Chris Packham
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqbo1g9vua.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=Matthieu.Moy@grenoble-inp$(echo .)fr \
--cc=a.krey@gmx$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
--cc=noufal@nibrahim$(echo .)net.in \
--cc=thomas@koch$(echo .)ro \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox