From: "Štěpán Němec" <stepnem@gmail.com>
To: Sverre Rabbelier <srabbelier@gmail.com>
Cc: Mark Lodato <lodatom@gmail.com>,
git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: [PATCH] CodingGuidelines: Add a section on writing documentation
Date: Mon, 01 Nov 2010 18:00:02 +0100 [thread overview]
Message-ID: <87fwvl2d4d.fsf@gmail.com> (raw)
In-Reply-To: <AANLkTinyPkGmsgbGM9qpXMNcZRzOXvtjDDEkJ-i3nWXz@mail.gmail.com> (Sverre Rabbelier's message of "Fri, 29 Oct 2010 10:14:20 -0700")
Sverre Rabbelier <srabbelier@gmail.com> writes:
> Heya,
>
> On Fri, Oct 29, 2010 at 04:54, Štěpán Němec <stepnem@gmail.com> wrote:
>> But given that it's only used as {0,2} at the two places right now
>> (disregarding occurences of "0{40}" in the documentation), I agree it
>> might be better to get rid of it, although I don't feel strongly about
>> it. Any other opinions?
>
> Let's get rid of it for now, we can always resurrect it later if we
> have a need for it.
OK.
>> I thought about this already when preparing the recent unification
>> series, and came to the conclusion "no, there shouldn't". :-) As the
>> examples you give show, the current usage is inconsistent, but given
>> that it brings no semantic ambiguity, I don't think it is a problem. You
>> could find more similar cosmetic inconsistencies and I don't think it
>> makes much sense to mandate any rules for such things. (But again, I
>> don't feel _too_ strongly about this either, so if more people think
>> it's worth it, I can prepare a patch that unifies them and mention the
>> preference in CodingGuidelines.)
>
> Perhaps we can set a standard to do it, but just leave the existing
> cases as is (to prevent unneeded churn)? That way we'll eventually
> converge on something.
Hm... that seems like the worst solution to me -- if we do end up
standardizing this after all, any occurence of non-standard usage would
be a bug that needs fixing (think about it from the POV of a new
contributor who reads CodingGuidelines but sees the actual usage being
different).
I guess it wouldn't be so much of a code churn to unify the spacing, but
I'm still not convinced we should be enforcing this kind of thing.
Štěpán
next prev parent reply other threads:[~2010-11-01 17:01 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-08 0:52 [PATCH/RFC] Unify argument and option notation in the docs Štěpán Němec
2010-10-08 7:43 ` Jonathan Nieder
2010-10-08 11:13 ` Štěpán Němec
2010-10-08 17:31 ` [PATCH 0/6] " Štěpán Němec
2010-10-08 17:44 ` Jonathan Nieder
2010-10-08 19:43 ` Junio C Hamano
2010-10-08 20:15 ` Štěpán Němec
2010-10-21 22:21 ` Jonathan Nieder
2010-10-24 15:51 ` [PATCH] CodingGuidelines: Add a section on writing documentation Štěpán Němec
2010-10-29 2:56 ` Mark Lodato
2010-10-29 11:54 ` Štěpán Němec
2010-10-29 17:14 ` Sverre Rabbelier
2010-11-01 17:00 ` Štěpán Němec [this message]
2010-11-04 17:12 ` [PATCH v2] " Štěpán Němec
2010-11-04 17:18 ` [PATCH] diff,difftool: Don't use the {0,2} notation in usage strings Štěpán Němec
2010-11-04 17:22 ` Sverre Rabbelier
2010-11-04 17:49 ` Jeff King
2010-11-04 18:02 ` Jonathan Nieder
2010-11-04 18:13 ` Jeff King
2010-11-04 18:38 ` Jonathan Nieder
2010-11-04 18:55 ` Jeff King
2010-11-04 20:26 ` Štěpán Němec
2010-11-04 20:43 ` Jeff King
2010-11-04 21:17 ` [PATCH] docs: clarify git diff modes of operation Jeff King
2010-11-04 21:50 ` Jonathan Nieder
2010-11-05 1:57 ` Mark Lodato
2010-11-04 21:51 ` Štěpán Němec
2010-11-04 21:30 ` [PATCH] diff,difftool: Don't use the {0,2} notation in usage strings Štěpán Němec
2010-10-08 17:31 ` [PATCH 1/6] Use angles for placeholders consistently Štěpán Němec
2010-10-08 17:31 ` [PATCH 2/6] Fix odd markup in --diff-filter documentation Štěpán Němec
2010-10-08 17:39 ` Jonathan Nieder
2010-10-08 17:57 ` Štěpán Němec
2010-10-08 18:03 ` Jonathan Nieder
2010-10-08 18:40 ` Štěpán Němec
2010-10-08 18:53 ` Jonathan Nieder
2010-10-08 17:31 ` [PATCH 3/6] Use parentheses and `...' where appropriate Štěpán Němec
2010-10-08 17:31 ` [PATCH 4/6] Remove stray quotes in --pretty and --format documentation Štěpán Němec
2010-10-08 17:31 ` [PATCH 5/6] Put a space between `<' and argument in pack-objects usage string Štěpán Němec
2010-10-08 17:31 ` [PATCH 6/6] Fix {update,checkout}-index usage strings Štěpán Němec
2010-10-08 16:45 ` [PATCH 0/2] pack-objects: use ALLOC_GROW in place of manual growth Jonathan Nieder
2010-10-08 16:46 ` [PATCH 1/2] Documentation: No argument of ALLOC_GROW should have side-effects Jonathan Nieder
2010-10-08 16:47 ` [PATCH 2/2] pack-objects: use ALLOC_GROW Jonathan Nieder
2010-10-08 17:02 ` [PATCH 3/2] Allow side-effects in second argument to ALLOC_GROW Jonathan Nieder
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=87fwvl2d4d.fsf@gmail.com \
--to=stepnem@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
--cc=lodatom@gmail.com \
--cc=srabbelier@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.
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.