> 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.
Okay, changed to
+ * This shouldn't be be set by the Makefile or by the user (e.g. via
+ * CFLAGS).
My intent is not to get hung up on any of these points, so I'm also
happy to punt on this or any hunk.
I'll send out new versions of the patches which apply to maint,
master, next, and pu in a bit.
-Justin
On Sat, Mar 22, 2014 at 4:47 PM, Jason St. John <jstjohn@xxxxxxxxxx> wrote:
> On Thu, Mar 20, 2014 at 7:13 PM, Justin Lebar <jlebar@xxxxxxxxxx> wrote:
>> 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.
>
>>> 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.
>
>>> This would be better worded as "If src_buffer and *src_buffer are not NULL, it should ..."
>>
>> Done.
>>
>> -Justin
>
> Jason
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html