Re: obnoxious CLI complaints

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



John Tapsell wrote:
2009/9/13 Dmitry Potapov <dpotapov@xxxxxxxxx>:
On Sat, Sep 12, 2009 at 09:32:09PM +0300, John Tapsell wrote:
2009/9/12 Dmitry Potapov <dpotapov@xxxxxxxxx>:
On Wed, Sep 09, 2009 at 05:09:31PM -0700, Brendan Miller wrote:
On Wed, Sep 9, 2009 at 2:54 PM, Jakub Narebski <jnareb@xxxxxxxxx> wrote:
Brendan Miller <catphive@xxxxxxxxxxxx> writes:
Is the goal of interface design to make
it difficult so I need to learn a lot of things, or easy so I can
remain blissfully ignorant but still do what I want?
Neither. You cannot get what unless you have specified what you want,
and for that you have to learn how to say that. Having good defaults is
very important, but the problem with choosing them is that people have
different preferences about them. For instance, you wanted the default
prefix for git-archive to be $myproject. For me, a good default would be
either $tag_name, or $myproject-$tag_name, or empty (as it is now!). So,
what you propose is *never* a good default for me. Moreover, changing
any default will cause a lot of pain for other people who use Git now.
Besides, writing something like --prefix='' is very ugly. So, the
current default makes perfect sense.
Ah, great logic.  You can't find a default that will suit everyone,
therefore don't bother.
I did not say "don't bother". On contrary, I said that defaults are very
important, but, in this case, the current default makes far more sense
that what was proposed by Brendan.

Yeah, I've been reading them. I'm saying that the docs are a crutch.
RTFM is the problem not the solution. It makes the user do more work
to avoid fixing usability issues.
A usability issue exists when a person knows how to do that, but it is
inconvenient or error-prone; or when a learning curve is too steep.
But when someone cannot use, let's say, a compiler, because he or she
refuses to read to learn the language, it is not a usability issue.
It's a usability issue when it doesn't just do the right thing in the
majority of cases and lets you specify what you want it to do in the
rest of the cases.
It does the right thing for me, and not just in most cases, it does so
in _all_ cases, because it does exactly it is told to do. And it is a
very important characteristics for any VCS, otherwise you can mess up
things easily. What is also good about Git is that it does not require
much keystrokes to do even rather complex stuff. And many defaults and
commands are configurable, so you can adjust it to your workflow. So,
I am not sure what your problem is.

Because I wouldn't call this just a few keystrokes to do the common case:

    git archive --format=tar --prefix=HEAD/ HEAD | gzip > head.tar.gz

I honestly don't understand the backlash against Brenden's point that
this could be made a bit simpler.

Be made simpler for whom? The first rule of defaults is that they are never correct.

And, to every one, if you don;t think like the way <SOME_PROGRAM> has it's defaults set and the developer(s) don't agree to change the default for _everyone_ to what _you_ like, you can still use your shell's alias facility to fix the situation for your own use case.

To channel Junio, why are we still having this discussion?
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]