Re: [RFC/PATCH 0/2] place cherry pick line below commit title

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/03/2016 03:13 PM, Junio C Hamano wrote:
Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes:

There are other options like checking for indentation or checking for
balanced parentheses/brackets, but I think that these would lead to
surprising behavior for the user (this would mean that whitespace or
certain characters could turn a valid trailer into an invalid one or
vice versa, or change the behavior of trailer.ifexists, especially
"replace").

Yes, that is exactly why I said that it may be necessary for the
code to analize the lines in a block identified as "likely to be a
trailing block" more carefully.  We can afford to be loose as long
as the only allowed operation is to append one at the end, but once
we start removing/replacing an existing entry, etc., the definition
of what an entry is becomes very much relevant.

I agree, and I was trying to discuss the possible alternatives for the definition of what an entry is in my previous e-mail.

If you think that the alternatives are still too loose, I'm not sure if we can make it any tighter. As far as I know, we're dealing with trailers like the following:

  Signed-off-by: A <author@xxxxxxxxxxx>
  [This has nothing to do with the above line]
  Signed-off-by: B <buthor@xxxxxxxxxxx>

and:

  Link 1: a link
    a continuation of the above

and:

  Signed-off-by: Some body <some@xxxxxxx> (comment
  on two lines)

As I stated in the quoted paragraph, one possibility is to use indentation and/or balanced parentheses/brackets to determine if a trailer line continues onto the next line, and this would handle all the above cases, but I still think that these would lead to surprising behavior. Hence my suggestion to just simply define it as a single physical line. But if you think that the pros (of the more complicated approach) outweigh the cons, I'm OK with that.

One alternative is to postpone this decision by changing sequencer only (and not trailer) to tolerate other lines in the trailer. This would make them even more divergent (sequencer supports arbitrary lines while trailer doesn't), but they were divergent already (sequencer supports "(cherry picked by" but trailer doesn't).



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]