Re: obnoxious CLI complaints
- From
A Large Angry SCM <gitzilla@gmail.com>
- Date
- Sep 12, 2009, 22:35 UTC
- Message-ID
- <4AAC224F.9080606@gmail.com>
- In-Reply-To
- <43d8ce650909121521m3dbac12co7f5f2dcaf15190e7@mail.gmail.com>
John Tapsell wrote:
Show 49 quoted lines
> 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.
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?