[PATCH 3 of 3 RFC] import: add new --faithful flag to use metadata but relax checks

[Kevin Bullock]

> On Mar 27, 2016, at 13:16, Pierre-Yves David <pierre-yves.david at ens-lyon.org> wrote:
> 
> On 03/11/2016 01:12 PM, Augie Fackler wrote:
>> On Fri, Mar 11, 2016 at 3:11 PM, Pierre-Yves David
>> <pierre-yves.david at ens-lyon.org> wrote:
>>> 
>>> 
>>> On 03/11/2016 06:25 PM, Augie Fackler wrote:
>>>> 
>>>> # HG changeset patch
>>>> # User Augie Fackler <augie at google.com>
>>>> # Date 1457539063 18000
>>>> #      Wed Mar 09 10:57:43 2016 -0500
>>>> # Node ID 7d53477e4496e8f2b16b12ed445407e79bbb787b
>>>> # Parent  602504c64084d85820c883a43b02951a61e992f5
>>>> # EXP-Topic import
>>>> import: add new --faithful flag to use metadata but relax checks
>>>> 
>>>> Sometimes it's helpful to import a patch with as much of the metadata
>>>> (especially parents) intact as possible, but some bit of extra didn't
>>>> make the trip through the exported patch. This gives users a tool to
>>>> preserve as much metadata as possible without having to get an exact
>>>> byte-for-byte match on the import process.
>>> 
>>> 
>>> In my opinion, the key part here is to:
>>> 1) bypass working copy
>>> 2) use the parent informations
> 
> I'm not sure we should automatically turn the bypassing here. Having a flag that make sure a patch is applied on parent.
> 
> (On the same "perpendicular" but important topic, there is the question of updating on the result or not).
> 
>>> I would rather see a name related to parents that "faithful". I don't
>>> "faithful" is very explicite and it mostly make sense in regards with
>>> --exact.
>> 
>> I'm not in love with the name "faithful", so I'd love constructive
>> suggestions about what we could name the flag.
> 
> The important part here is the fact we read and use the parent information in the patch. So I think having "parent" in the name make sense:
> 
>  --originalparents
>  --useparents
>  --onparents
>  --parents
>  --onorigin
> 
> I think --useparents is my favorite but I don't have a strong opinion.

It seems like we have three classes of metadata here:

1. user, date, description, branch name - always imported, no problems here
2. node id + original parent (others?) - can be used as hints in importing
3. extra data that is part of the commit hash but not the patch - causes problems with --exact

For the sake of completeness, though it's probably a bad idea: Would it be reasonable to make --exact behave like your new flag instead? When --exact first appeared there were fewer things that wrote into extra, thus fewer ways that an export could fail to exactly represent a commit. (transplant_source notably dates from before import --exact.)

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
Kevin R. Bullock