From: Jari Aalto <jari.aalto@cante.net>
To: git@vger.kernel.org
Subject: Re: [PATCH] git-commit.txt: Order options alphabetically
Date: Thu, 02 Dec 2010 01:02:15 +0200 [thread overview]
Message-ID: <87aakpt7uw.fsf@picasso.cante.net> (raw)
In-Reply-To: E02740CE-37EE-4701-BB2D-18AD493D1C05@sb.org
2010-12-02 00:52 Kevin Ballard <kevin@sb.org>:
> On Dec 1, 2010, at 2:45 PM, Jari Aalto wrote:
>> What is the reason --reset-author is in that position? What
>
> It's entirely possible...
The reader have to guess "imagined groups"? Hm, that's interesting.
>> To me the git-pages do not look that professional...
>
> You seem overly concerned with the visual aesthetics and not at all with the
> actual content.
Humans read visually. It's built in. Distractions slow down. Try writing
abcdef = 1
x123.213.123..123. = 4
sdaölkasd = 1
vs.
abcdef = 1
x123.213.123..123. = 4
sdaölkasd = 1
There is a reason why people like Excel cells. Not my invention.
>> When the pages list options in alphabetical order, it doesn't take long
>> to compare commands: similarities and differences in options, or missing
>> options, or inconsistencies for that matter.
>
> Why would you compare commands like that? There's really no reason at all to
> believe that the -c flag for one command is even related to the -c flag for
> another command.
I take it you have written loads of software. The reasons come from
standard Software Development and Quality auditions. Git's command line
is inconsistent in many places and there is room for improvement.
Documentation is one way to spot those.
And ther eis perfect reasons to, again, expect consistency on some level
of command options to mean same thing
Like why some commands need number in:
-n NUMBER
Whereas other's use:
-NUMBER
Examples like that.
Jari
next prev parent reply other threads:[~2010-12-01 23:02 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-01 14:58 [PATCH] git-commit.txt: Order options alphabetically jari.aalto
2010-12-01 16:50 ` Jonathan Nieder
2010-12-01 17:16 ` Jari Aalto
2010-12-01 17:48 ` Jakub Narebski
2010-12-01 18:39 ` Jari Aalto
2010-12-02 14:27 ` Jakub Narebski
2010-12-01 19:30 ` Junio C Hamano
2010-12-01 21:58 ` Kevin Ballard
2010-12-01 22:45 ` Jari Aalto
2010-12-01 22:52 ` Kevin Ballard
2010-12-01 23:02 ` Jari Aalto [this message]
2010-12-02 8:53 ` Jan Krüger
2010-12-02 12:03 ` Jari Aalto
2010-12-02 14:23 ` Jakub Narebski
2010-12-02 19:30 ` Jan Krüger
2010-12-01 22:35 ` Jari Aalto
2010-12-01 22:49 ` Kevin Ballard
2010-12-01 23:05 ` Jari Aalto
2010-12-01 23:40 ` Kevin Ballard
2010-12-02 5:35 ` Jari Aalto
2010-12-03 12:10 ` Erik Faye-Lund
2010-12-03 13:03 ` Nguyen Thai Ngoc Duy
-- strict thread matches above, loose matches on Subject: below --
2010-12-01 15:52 jari.aalto
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87aakpt7uw.fsf@picasso.cante.net \
--to=jari.aalto@cante.net \
--cc=git@vger.kernel.org \
/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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.