From: John Tapsell <johnflux@gmail.com>
To: Dmitry Potapov <dpotapov@gmail.com>
Cc: Brendan Miller <catphive@catphive.net>,
Jakub Narebski <jnareb@gmail.com>,
git@vger.kernel.org
Subject: Re: obnoxious CLI complaints
Date: Sun, 13 Sep 2009 01:21:43 +0300 [thread overview]
Message-ID: <43d8ce650909121521m3dbac12co7f5f2dcaf15190e7@mail.gmail.com> (raw)
In-Reply-To: <20090912214428.GB30385@dpotapov.dyndns.org>
2009/9/13 Dmitry Potapov <dpotapov@gmail.com>:
> On Sat, Sep 12, 2009 at 09:32:09PM +0300, John Tapsell wrote:
>> 2009/9/12 Dmitry Potapov <dpotapov@gmail.com>:
>> > 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@gmail.com> wrote:
>> >> > Brendan Miller <catphive@catphive.net> 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.
John
next prev parent reply other threads:[~2009-09-12 22:25 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-09 21:27 obnoxious CLI complaints Brendan Miller
2009-09-09 21:54 ` Jakub Narebski
2009-09-09 22:06 ` Wincent Colaiuta
2009-09-10 16:50 ` Jakub Narebski
2009-09-10 18:53 ` Junio C Hamano
2009-09-10 22:19 ` René Scharfe
2009-09-11 3:15 ` Björn Steinbrink
2009-09-10 19:46 ` John Tapsell
2009-09-10 20:17 ` Sverre Rabbelier
2009-09-10 20:23 ` Jakub Narebski
2009-09-10 22:04 ` John Tapsell
2009-09-10 22:49 ` Junio C Hamano
2009-09-10 23:19 ` demerphq
2009-09-11 0:37 ` Junio C Hamano
2009-09-11 0:18 ` John Tapsell
2009-09-11 0:25 ` Junio C Hamano
2009-09-10 0:09 ` Brendan Miller
2009-09-10 1:25 ` Todd Zullinger
2009-09-10 9:16 ` Jakub Narebski
2009-09-10 18:18 ` Eric Schaefer
2009-09-10 18:52 ` Sverre Rabbelier
2009-09-10 22:19 ` René Scharfe
2009-09-11 14:47 ` Linus Torvalds
2009-09-11 22:01 ` René Scharfe
2009-09-11 22:16 ` Linus Torvalds
2009-09-12 10:31 ` Dmitry Potapov
2009-09-12 18:32 ` John Tapsell
2009-09-12 21:44 ` Dmitry Potapov
2009-09-12 22:21 ` John Tapsell [this message]
2009-09-12 22:35 ` A Large Angry SCM
2009-09-12 22:43 ` Dmitry Potapov
2009-09-12 23:08 ` John Tapsell
2009-09-13 2:47 ` Junio C Hamano
2009-09-13 17:36 ` [PATCH 1/2] git-archive: add '-o' as a alias for '--output' Dmitry Potapov
2009-09-13 17:36 ` [PATCH 2/2] teach git-archive to auto detect the output format Dmitry Potapov
2009-09-13 18:52 ` Junio C Hamano
2009-09-13 20:17 ` [PATCH v2 " Dmitry Potapov
2009-09-13 21:27 ` Junio C Hamano
2009-09-13 18:34 ` [PATCH 1/2] git-archive: add '-o' as a alias for '--output' Junio C Hamano
2009-09-13 20:13 ` [PATCH v2 " Dmitry Potapov
2009-09-17 0:48 ` obnoxious CLI complaints Brendan Miller
2009-09-17 1:27 ` Junio C Hamano
2009-09-09 21:58 ` Sverre Rabbelier
2009-09-09 22:58 ` Pierre Habouzit
2009-09-10 1:32 ` Björn Steinbrink
2009-09-10 18:54 ` Matthieu Moy
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43d8ce650909121521m3dbac12co7f5f2dcaf15190e7@mail.gmail.com \
--to=johnflux@gmail.com \
--cc=catphive@catphive.net \
--cc=dpotapov@gmail.com \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).