Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes:
> On Sun, 17 Aug 2008, Trans wrote:
>
>> Well, after a few days of using git, I've decide Linus is too smart to
>> be designing end-user interfaces.
>
> This is true, but hardly relevant. Git's end-user interface was almost
> entirely designed by other people, using Linus's excellent
> script-developer API.
I'd agree that you cannot judge Linus's ability to design end-user
interfaces by observing the UI of git.
I am pleased to see that almost everybody who responded in this thread has
refrained from saying meaningless things (aka feeding the troll) to waste
people's mental bandwidth.
I think there are three majorly different reasons that new people can get
confused.
(1) Some concepts in git are different from what people from other systems
are used to. For example, A new person may be puzzled by the
distinction among "git diff", "git diff HEAD" and "git diff --cached"
and say "why do you have these three?"
Complaining that we have these three instead of two, claiming that
such complexity is a source of UI clunkiness, is an invalid argument
made by a new person who does not understand the index. People who do
take advantage of the index need the distinction among these three.
We shouldn't be doing anything but educate them against that kind of
complaints.
However, I think it is valid to say, for a person who does not use
index very actively (i.e. one who does not incrementally stage), what
"git diff" does is confusing. It does not say anything about new
files (until it is modified since added) while showing changes for
existing files. CVS does the same thing ("file foo is a newly added
file, no comparison available"), but that may not be a good excuse.
If we had a configuration for "index-free" people, that changes the
semantics of "git add" to register object name of an empty blob when a
new path is added, makes "git add" for existing blobs a no-op, but
keeps "git commit -a" and "git commit <paths>" to operate as they
currently do, then people with such configuration could:
$ >new-file
$ git add new-file
$ edit old-file
$ edit new-file
$ git diff
to always see what's the difference from the HEAD is with "git diff",
and any of these three:
$ git commit -a
$ git commit old-file
$ git commit old-file new-file
would work as expected by them. We still need to support the three
diff variants for normal git people, but people who do not use index
do not have to know the two variants ("git diff" vs "git diff HEAD");
such a change could be argued as a "UI improvement" [*1*].
(2) Some concepts in git are different from what they are used to, without
any good reason. IOW, the concepts have room for improvement, and our
UI is based on these faulty concepts.
(3) Some concepts in git may be exactly the same with other systems, yet
our UI may operate differently from them without any good reason.
I'd be surprised if there is _no_ UI element that falls into the latter
two categories, but obviously I would not be able to list examples. If I
could, they instead would have long been fixed already.
[Footnote]
*1* I need to stress that this is just an example for example's sake. I
personally do not think such an index-free "training wheel" configuration
is a good idea.
--
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
