Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > On Sat, Nov 30, 2019 at 10:35 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: >> >> OK, so it appears that the tool is working as documented. > > Well, yes and no. > > I think it's a mistake that --no-keep-cr (which is the default) only > acts on the outer envelope. > > Now, *originally* the outer envelope was all that existed so it makes > sense in a historical context of "CR removal happens when splitting > emails in an mbox". And that's the behavior we have. Hmph, first of all, the one I was referring to as "documented" was about --ignore-whitespace, and not --no-keep-cr. And I am not as sure as you seem to be about "--no-keep-cr" either. What was the reason why "--no-keep-cr" was invented and made default? Wasn't it because RFC says that each line of plaintext transfer of an e-mail is terminated with CRLF? It would mean that, whether the payload originally had CRLF terminated or LF terminated, we would not be able to tell---the CR may have been there from the beginning, or it could have been added in transit. And because we (the projects Git was originally designed to serve well) wanted our patches with LF terminated lines most of the time, it made sense to strip CR from CRLF (i.e. assuming that it would be rare that the sender wants to transmit CRLF terminated lines). If the contents were base64 protected from getting munged during transit, we _know_ CRLF in the payload after we decode MIME is what the sender _meant_ to give us, no? Which leads me to say ... > > But then git learnt to do MIME decoding and extracting things from > base64 etc, and the CR removal wasn't updated to that change. ... I do not think it was a wrong decision (well, I do not think we made the conscious decision to do so, though) not to do that update. I dunno.
