Re: [PATCH 2/5] t/t3511: demonstrate breakage in cherry-pick -s

From: Brandon Casey <drafnel@gmail.com>
Date: Nov 16, 2012, 02:40 UTC
Message-ID: <CA+sFfMfvZg5An5sZ4TvXM5k_op5WwhvKgma3Mq4bX9NG-a6-Cg@mail.gmail.com>
In-Reply-To: <7v8va28g1c.fsf@alter.siamese.dyndns.org>

On Thu, Nov 15, 2012 at 5:58 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 10 quoted lines

> Brandon Casey <drafnel@gmail.com> writes:
>
>> The cherry-pick -s functionality is currently broken in two ways.
>>
>>    1. handling of rfc2822 continuation lines has a bug, and the
>>       continuation lines are not handled correctly.
>
> This is not limited to you, but people should think twice when
> writing "has a bug" and "are not handled correctly" in their log
> message.  Did you write what the expected and actual behaviours?

Yeah, I wasn't clear here. The "bug" was that the incorrect index variable was being used, which caused the wrong line to be examined to see if it was an rfc2822 continuation line. I could have mentioned that.

Show 9 quoted lines

>> +rfc2822_mesg="$non_rfc2822_mesg
>> +
>> +Signed-off-by: A.U. Thor
>> + <author@example.com>
>> +Signed-off-by: B.U. Thor <buthor@example.com>"
>
> The S-o-b: lines are meant to record people's contact info in human
> readable forms, and folding the lines like the above makes it a lot
> harder to read.  They typically do not have to be folded.

Well, I wasn't adding functionality here, I was only fixing what I noticed was broken when I started touching this code.

Show 6 quoted lines

> Besides, the footer lines are *not* RFC2822 headers (and are not
> used as such when send-email comes up with Cc: list) in the first
> place; have we ever said anything about supporting the RFC2822 line
> folding in the commit footer?  If not (and I am reasonably sure we
> never have), I personally think we should actively *discourage* line
> folding there.

That's fine with me. I can't think of a reason that would make it necessary to support line continuation.

Show 15 quoted lines

>>       i.e. we should produce this:
>>
>>          Signed-off-by: A.U. Thor <author@example.com>
>>          (cherry picked from )
>>          Signed-off-by: C O Mmitter <committer@example.com>
>>
>>       not
>>
>>          Signed-off-by: A.U. Thor <author@example.com>
>>          (cherry picked from da39a3ee5e6b4b0d3255bfef95601890afd80709)
>>
>>          Signed-off-by: C O Mmitter <committer@example.com>
>
> I can buy that, but then this makes it very clear that these footer
> lines are not shaped like RFC2822 headers, no?

The lines that are _not_ "(cherry picked from ...)" lines do follow the format defined by rfc2822 for header lines (mostly). That's probably why the author of the function in sequencer.c that checks for a s-o-b footer named it "ends_rfc2822_footer".

I'll remove the *broken* existing code that was intended to support continuation lines and submit a new patch.

-Brandon