[PATCH 1 of 2 RFC] export: list all key/values from extra in the patch header

Yuya Nishihara yuya at tcha.org
Fri Dec 25 07:16:01 CST 2015


On Sun, 20 Dec 2015 22:52:26 -0500, Matt Harbison wrote:
> # HG changeset patch
> # User Matt Harbison <matt_harbison at yahoo.com>
> # Date 1450661679 18000
> #      Sun Dec 20 20:34:39 2015 -0500
> # Node ID eff20351cc9b29232493885887e82576f772d1b6
> # Parent  5df74b2f296df7f44a08106df4f9dd97a5aa726a
> export: list all key/values from extra in the patch header
> 
> This uses the existing mechanism for extensions to export data in the header,
> but deviates from the design of handling specific keys.  That seems reasonable
> for core behavior, since:
> 
>   1) I don't see any way to locate all of the extras used in core and hgext/
>   2) Even if there was, I'm not sure that there's a way to enforce handling them
>      here
>   3) Even if there was, exporting via a new hg and importing with an older one
>      would result in silent data loss.

I'm not excited about this. I think most of extra data (e.g. amend_source)
are noisy rather than informative.

> If each extension handled the import/export processing for its own keys, that
> would mean the extension would need to be loaded for both import and export.
> That may not be reasonable for some extensions.  (e.g. I only load convert when
> actively converting something.)  This doesn't preclude extensions from adding
> headers.  For example, it may be useful for transplant to emit a human readable
> header for 'transplant_source', since the raw value is an escaped binary.  No
> processing would be necessary on import, since the raw key/value is still
> present.

Really? IIRC, 'transplant_source' is an unescaped binary node id, which may
contain random bytes including NUL, CR and LF.


More information about the Mercurial-devel mailing list