From: Junio C Hamano <firstname.lastname@example.org>
To: Pratyush Yadav <email@example.com>
Cc: Shourya Shukla <firstname.lastname@example.org>,
Subject: Re: [PATCH 1/2] gitfaq: cleanup gitfaq.txt
Date: Fri, 10 Apr 2020 11:29:00 -0700 [thread overview]
Message-ID: <email@example.com> (raw)
In-Reply-To: <firstname.lastname@example.org> (Pratyush Yadav's message of "Wed, 8 Apr 2020 23:52:47 +0530")
Pratyush Yadav <email@example.com> writes:
> Maybe we should just have a consistent convention throughout the
> documentation on whether to use one space after a full-stop or two.
> Right now in some places we use one space, in some others we use two,
> even in the same file. This is slightly distracting when reading.
As somebody who almost always goes to the source on a fixed width
font terminal and not to formatted output, I personally find it
distracting not to have the extra space at the end of a sentence.
> And FWIW, our man pages are always
> rendered with one space, even if the source file has two.
Or three, for that matter ;-)
It is one of the reasons why we didn't really care and have not gone
churning the source.
> Having a convention would at least result in uniformity, even if
> it won't end the debate on which is better.
Yup. If I were to dictate a convention, I'd say we should have one
extra space after a full-stop or similar that ends a sentence.
As you pointed out, the choice of the convention does not make any
difference to the end product for end users, and only affect those
who work on the source with mark-ups, that is a fairly easy thing
to declare, without letting anybody argue for or against---it is not
better or worse than the other choice, but choosing one and sticking
to it is probably much better than not having a uniform convention.
Having said that, let's not go berserk and start reformatting,
especially areas that are actively touched for non-stylistic
reasons. Those other changes are much much more important.
next prev parent reply other threads:[~2020-04-10 18:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-06 18:12 [PATCH 0/2] Add more issues in gitfaq Shourya Shukla
2020-04-06 18:12 ` [PATCH 1/2] gitfaq: cleanup gitfaq.txt Shourya Shukla
2020-04-06 19:06 ` Junio C Hamano
2020-04-06 23:46 ` Junio C Hamano
2020-04-07 1:07 ` brian m. carlson
2020-04-07 3:15 ` Junio C Hamano
2020-04-08 18:22 ` Pratyush Yadav
2020-04-10 18:29 ` Junio C Hamano [this message]
2020-04-06 18:12 ` [PATCH 2/2] gitfaq: append the 'Common Issues' section Shourya Shukla
2020-04-06 19:28 ` Junio C Hamano
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:
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 \
* 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
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).