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.

> How about ``If none of "always", "never", or "auto" is specified, then 
> setting layout
> implies "always".``?


> 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)."

> This would be better worded as "If src_buffer and *src_buffer are not NULL, 
> it should ..."


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to