indygreg added a comment.
This is more of an RFC patch. My actual goal is support for ingesting CBOR patches via `hg import`. I figured it would be easier to test that if we had support for CBOR with `hg export`. And the reason I want CBOR support for patch ingestion is because it is safer: it reduces the surface area for injecting badness via patch parsing. See e.g. http://rachelbythebay.com/w/2018/04/05/bangpatch/. This implementation is still only partially there: I think a better approach would be to have structured data for the diffs so we don't need to parse those either. That would allow us to use binary data without escaping, not have to use inline text metadata for copy/renames, not have to worry about encoding of filenames, etc. All the problems with "parse a patch" go away and you are left with commit metadata and a series of splicing instructions, which should be pretty generic. The I/O in the export code is pretty wonky. I'm kinda sad that `cbor2` insists on binding an encoder/decoder to a file object. I *really* wish you could get straight bytes out of it without having to use `io.BytesIO()`. I suspect someone is going to tell me that `hg export` should use the templating layer. If someone does, I would appreciate help implementing that. Of course, for us to get CBOR with the templating layer, we'd have to teach the templating layer to emit CBOR. Since we can emit JSON, CBOR seems reasonable. I'm just not too familiar with that code though. REPOSITORY rHG Mercurial REVISION DETAIL https://phab.mercurial-scm.org/D3175 To: indygreg, #hg-reviewers Cc: mercurial-devel _______________________________________________ Mercurial-devel mailing list Mercurialfirstname.lastname@example.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel