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

Re: [PATCH 3/4] Fix misuses of "nor" in comments

From
Jason St. John <jstjohn@purdue.edu>
Date
Mar 22, 2014, 23:47 UTC
Message-ID
<CAEjxke-Qe=CYwR9akZ9anjjbO3Tf83f-Y0J4qOJ+i4pKZ=-vAQ@mail.gmail.com>
In-Reply-To
<CAMuNMfov+Z0Hx_a-hZ2ZGRdkTtw1eqUn01gWEQ+caT3VcHZkVQ@mail.gmail.com>
On Thu, Mar 20, 2014 at 7:13 PM, Justin Lebar <jlebar@google.com> wrote:
Show 33 quoted lines
> Thanks for the quick reply.
>
> When I send a new patch, should I fold these changes into the original
> commit, or should I send them as a separate commit?
>
>>> diff --git a/builtin/apply.c b/builtin/apply.c
>>> index b0d0986..6013e19 100644
>>> --- a/builtin/apply.c
>>> +++ b/builtin/apply.c
>>> @@ -4061,7 +4061,7 @@ static int write_out_one_reject(struct patch *patch)
>>>                 return error(_("cannot open %s: %s"), namebuf, strerror(errno));
>>>
>>>         /* Normal git tools never deal with .rej, so do not pretend
>>> -        * this is a git patch by saying --git nor give extended
>>> +        * this is a git patch by saying --git or giving extended
>>>          * headers.  While at it, maybe please "kompare" that wants
>>>          * the trailing TAB and some garbage at the end of line ;-).
>>>          */
>>
>> I don't think the change from "give" to "giving" here is grammatically correct.
>
> Is it?  I might be misunderstanding the sentence, then.  I parse the
> new sentence as
>
>   Do not pretend this is a git patch by
>   - saying --git, or
>   - giving extended headers.
>
> "Giving" is definitely awkward, but I'm not sure of a better word.
>
> I'm happy to rephrase this, but I'm not sure how.  I don't think the
> original makes much sense, but I'm also happy to leave it.
>
You're right; that makes sense. Disregard my comment about that chunk.
Show 13 quoted lines
>> How about ``If none of "always", "never", or "auto" is specified, then setting layout
>> implies "always".``?
>
> Sure.
>
>> To leave "nor" here, I think you need to replace "not" with "neither".
>
> I think it actually works after the change, but unfortunately Garner's
> doesn't give me a lot of ammunition to back up that feeling.  :)
>
> How about "We don't expect this to be set by the Makefile or by the
> user (via CFLAGS)."
>

I feel like I'm splitting hairs, but I think there's a change in meaning if you use that phrasing. The difference being "not expecting" vs. "should not". I don't know which is correct, so I'll defer that to someone else.

Show 5 quoted lines
>> This would be better worded as "If src_buffer and *src_buffer are not NULL, it should ..."
>
> Done.
>
> -Justin
Jason
Previous: Junio C HamanoNext: Justin Lebar
Message 9 of 11 in “Fix misuses of "nor" (v2)”
  1. 0/4 Fix misuses of "nor" (v2)Justin Lebar, Mar 20, 2014
  2. 1/4 Documentation: Fix misuses of "nor"Justin Lebar, Mar 20, 2014
  3. 2/4 contrib: Fix misuses of "nor"Justin Lebar, Mar 20, 2014
  4. 3/4 Fix misuses of "nor" in commentsJustin Lebar, Mar 20, 2014
  5. Jason St. JohnMar 20, 2014
  6. Justin LebarMar 20, 2014
  7. Junio C HamanoMar 21, 2014
  8. Junio C HamanoMar 21, 2014
  9. Jason St. JohnMar 22, 2014
  10. Justin LebarMar 29, 2014
  11. 4/4 Fix misuses of "nor" outside comments and in testsJustin Lebar, Mar 20, 2014

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.