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

[Augie Fackler]

> On Mar 29, 2016, at 9:23 AM, Kevin Bullock <kbullock+mercurial at ringworld.org> wrote:
> 
>> 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.)

Exact does what it says on the tin, preventing data loss. In a world where diff still can’t completely represent our changesets (eg mode changes without --git), exact’s semantics are actually valuable to some users (see also [0]). Fixing extra transmission would likely be a better approach than this flag, but that’s hard and this is easy.

0: https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-February/080245.html

> 
> pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
> Kevin R. Bullock
> 
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20160329/230da0f3/attachment.sig>