Junio C Hamano <gitster@xxxxxxxxx> writes: > Sean <seanlkml@xxxxxxxxxxxx> writes: > >> I would argue that you shouldn't try to have it both ways. > > You cannot have it both ways as-is, but this is solvable. The > invocation of am from rebase needs an extra (internal to > implementation) option to use the code it patches, and the > regular am can fold what are found on Subject: lines it used > to. > > The patch as-is breaks the more important case of e-mail > acceptance codepath, because MUAs are free to fold the Subject: > line when the original line is long, and what the user (the > original patch submitter) expects to happen is that a > single-line-ness of the original Subject: of the message to be > kept. The patch breaks such a line at the place MUA happens to > fold such a long, single line, for comforming messages. So here comes an updated series, properly split along the logical lines. 0001-log_ref_write-do-not-chomp-reflog-message-at-the.txt 0002-symbolic-ref-update-ref-do-not-refuse-reflog-message.txt 0003-rebase-try-not-to-munge-commit-log-message.txt I am not absolutely sure about the implications of mailinfo change. I tried to be careful by making sure that: - the updated code kicks in when "format-patch piped to am" toolchain uses the -k option on both ends, as rebase/am does. This is the case where we would want to keep the way original commit log message was formatted. - otherwise the original "line folding" clean-up is used, so that usual e-mailed patch acceptance codepath cleanses the oneline summary obtained from the "Subject:" header. Because it would be a serious regression to break the latter, while the former is just "an improvement" [*1], somebody really should double check the change for me. [Footnote] *1* It does not mean that improved support for foreign SCM interoperation does not matter. It is "merely an improvement" in the sense that people do not like what the code currently does anyway, and if the updated code is still not liked, then not having such "an improvement" does not matter. - 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
