git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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?
Previous: John TapsellNext: Dmitry Potapov
Message 30 of 46 in “obnoxious CLI complaints”
  1. Brendan MillerSep 9, 2009
  2. Jakub NarebskiSep 9, 2009
  3. Wincent ColaiutaSep 9, 2009
  4. Jakub NarebskiSep 10, 2009
  5. Junio C HamanoSep 10, 2009
  6. René ScharfeSep 10, 2009
  7. Björn SteinbrinkSep 11, 2009
  8. John TapsellSep 10, 2009
  9. Sverre RabbelierSep 10, 2009
  10. Jakub NarebskiSep 10, 2009
  11. John TapsellSep 10, 2009
  12. Junio C HamanoSep 10, 2009
  13. demerphqSep 10, 2009
  14. Junio C HamanoSep 11, 2009
  15. John TapsellSep 11, 2009
  16. Junio C HamanoSep 11, 2009
  17. Brendan MillerSep 10, 2009
  18. Todd ZullingerSep 10, 2009
  19. Jakub NarebskiSep 10, 2009
  20. Eric SchaeferSep 10, 2009
  21. Sverre RabbelierSep 10, 2009
  22. René ScharfeSep 10, 2009
  23. Linus TorvaldsSep 11, 2009
  24. René ScharfeSep 11, 2009
  25. Linus TorvaldsSep 11, 2009
  26. Dmitry PotapovSep 12, 2009
  27. John TapsellSep 12, 2009
  28. Dmitry PotapovSep 12, 2009
  29. John TapsellSep 12, 2009
  30. A Large Angry SCMSep 12, 2009
  31. Dmitry PotapovSep 12, 2009
  32. John TapsellSep 12, 2009
  33. Junio C HamanoSep 13, 2009
  34. 1/2 git-archive: add '-o' as a alias for '--output'Dmitry Potapov, Sep 13, 2009
  35. 2/2 teach git-archive to auto detect the output formatDmitry Potapov, Sep 13, 2009
  36. Junio C HamanoSep 13, 2009
  37. 2/2 teach git-archive to auto detect the output formatDmitry Potapov, Sep 13, 2009
  38. Junio C HamanoSep 13, 2009
  39. Junio C HamanoSep 13, 2009
  40. 1/2 git-archive: add '-o' as a alias for '--output'Dmitry Potapov, Sep 13, 2009
  41. Brendan MillerSep 17, 2009
  42. Junio C HamanoSep 17, 2009
  43. Sverre RabbelierSep 9, 2009
  44. Pierre HabouzitSep 9, 2009
  45. Björn SteinbrinkSep 10, 2009
  46. Matthieu MoySep 10, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.