Is it possible that git complains about everything that has ^M in it and rejects it (that is without trying to fix it, etc.) Regards, Amit On Sun, Dec 1, 2019 at 8:58 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > 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. >
