All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Blesius <alexander+git@blesius.eu>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] doc: fix typos in man pages
Date: Mon, 18 Mar 2019 09:54:06 +0100	[thread overview]
Message-ID: <9a283595-490e-81cd-9d88-4cc59ad893e9@blesius.eu> (raw)
In-Reply-To: <xmqqef744u2f.fsf@gitster-ct.c.googlers.com>


[-- Attachment #1.1: Type: text/plain, Size: 2120 bytes --]

On 18/03/2019 06:42, Junio C Hamano wrote:
>> diff --git a/Documentation/gitattributes.txt
>> b/Documentation/gitattributes.txt
>> index 9b41f81c06..908d9a3009 100644
>> --- a/Documentation/gitattributes.txt
>> +++ b/Documentation/gitattributes.txt
>> @@ -314,8 +314,8 @@ stored as UTF-8 internally. A client without
>> `working-tree-encoding`
>>  support will checkout `foo.ps1` as UTF-8 encoded file. This will
>>  typically cause trouble for the users of this file.
>>  +
>> -If a Git client, that does not support the `working-tree-encoding`
>> -attribute, adds a new file `bar.ps1`, then `bar.ps1` will be
>> +If a Git client that does not support the `working-tree-encoding`
>> +attribute adds a new file `bar.ps1`, then `bar.ps1` will be
> 
> Or s/that/which/.  I am not sure which one gives us a cleaner
> result.
> 
>     If a new file `bar.ps1` is added by a Git client that does not
>     understand `working-tree-encoding` attribute, then ...
> 
> is how I may write it, though.  I dunno.  Let's take yours at least
> for now and let others complain if they care deeply about it.
> 
>>  stored "as-is" internally (in this example probably as UTF-16).
>>  A client with `working-tree-encoding` support will interpret the
>>  internal contents as UTF-8 and try to convert it to UTF-16 on checkout.
> 
> Thanks.
> 


Hi,

sorry about the MUC wrapping, will be more careful next time :)

As I learned it, commas are used around relative clauses (sentences
introduced by "that", "which" etc.) only if they are non-defining, so if
the information inside that sentence is not necessary to understand the
sentence. While I'm not a native speaker and therefore unsure how much
that would matter to a reader, I think it's better to use the
grammatically correct version to avoid ambiguity.

The question whether that or which shouldn't matter too much, I think
both can be used interchangeably here.

Thanks for your feedback!

Best regards,
Alex
-- 
Alexander Blesius M.A.

Please consider encrypting your mails with PGP.
https://emailselfdefense.fsf.org/de/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2019-03-18  8:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-16 10:34 [PATCH] doc: fix typos in man pages Alexander Blesius
2019-03-18  5:42 ` Junio C Hamano
2019-03-18  8:54   ` Alexander Blesius [this message]
2019-03-18  7:09 ` Junio C Hamano

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=9a283595-490e-81cd-9d88-4cc59ad893e9@blesius.eu \
    --to=alexander+git@blesius.eu \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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.