? Seems still pretty brittle. > > > Actually already when committing... cause there it's taken as valid > > and > > then it should also work with any following tools. > > That would inconvenience all users that never use format-patch. Sure, the real solution would still be to do proper escaping. > Itâ??s not non-obvious either. The simple format is apparent if you > review your patches before sending them out into the world. (Iâ??m > paranoid so I do that) The whole arguing "the user must check what he writes in the commit message" seems a bit to me as if users would need to think about not being allowed to use characters like < etc. when they write text which might be stored as HTML, because that wouldn't provide a quoting mechanism which an editor could automatically employ. > Thatâ??s interesting and a good idea to use an email header to signal > the > escaping. My first idea was using MIME, but I guess many people wouldnâ??t be all too delighted seeing patches with MIME and the commit message encoded as base64 or so ;-) So any quoting should be still human readable (though git already does use some IMO not so human readable encoding for Subject: lines). Using something that is already standard would be of course nicer, but if it's not accepted, than better a simple schema that still works. > Thinking just about `^---$`: an email header could be generated if > `^---$` occurs in the commit message. Then it could suggest > something > non-occurring instead. Simply `-----` or `***` or something. Should work, but if one has strange enough commit messages, either the new separator would get stranger and stranger, or, if there was just a hardcoded list of alternatives, one could run out of alternatives. If a header would get introduced one should make it generic enough... e.g. to allow for different quoting schemas, or even to allow for completely other format information. > Some niggles: the commit message might just be the subject line and > there might be no diff (empty patch). Then looking for `^---$` will > take you too far. Maybe just look for the signature line. Another way might be to simply store in a header just how many lines of commit messages follow. But I think that would have also some downsides. Cheers, Chris.
