[PATCH STABLE] import: mark --exact as experimental

[Matt Mackall]

On Sat, 2016-02-27 at 00:18 +0100, Pierre-Yves David wrote:
> 
> On 02/26/2016 09:17 PM, Matt Mackall wrote:
> > On Thu, 2016-02-25 at 11:12 -0500, Augie Fackler wrote:
> > > On Thu, Feb 25, 2016 at 10:53:26AM +0100, Pierre-Yves David wrote:
> > > > # HG changeset patch
> > > > # User Pierre-Yves David <pierre-yves.david at fb.com>
> > > > # Date 1456060026 -3600
> > > > #Â Â Â Â Â Â Sun Feb 21 14:07:06 2016 +0100
> > > > # Branch stable
> > > > # Node ID a412b87ce53add0d4304de0170140bff1dc266b3
> > > > # Parent  cb6a952efbf48d306a7c82d7fe46115f072cbb1d
> > > > # EXP-Topic expexact
> > > > # Available At http://hg.netv6.net/marmoute-wip/mercurial/
> > > > #Â Â Â Â Â Â Â Â Â Â Â Â Â Â hg pull http://hg.netv6.net/marmoute-wip/mercurial/ -r
> > > > a412b87ce53a
> > > > import: mark --exact as experimental
> > > 
> > > +1, but I'm unsure if it belongs on stable. Matt?
> > 
> > I don't like this at all, sorry.
> > 
> > It works as advertised:
> > 
> > Â Â Â Â If --exact is specified, import will set the working directory to the
> > Â Â Â Â Â parent of each patch before applying it, and will abort if the
> > resulting
> > Â Â Â Â Â changeset has a different ID than the one recorded in the patch. This
> > may
> > Â Â Â Â Â happen due to character set problems or other deficiencies in the text
> > Â Â Â Â Â patch format.
> > 
> > This feature has never been a promise to perfectly transfer every possible
> > changeset. We've never been able to do that and it's unlikely that we ever
> > will.
> > And extra fields aren't even a significant obstacle to that.
> > 
> > Instead this feature is a promise to perfectly transfer OR REJECT anything
> > that
> > isn't perfectly transferred. So everything you apparently think is a bug is
> > actually it doing its data-integrity-protecting job.
> 
> Okay, that precise feature work as advertised "A perfect importer with 
> integrity check". And integrity check are cool, their are not what I'm 
> calling a bug here. The issue lies in the fact that this perfect 
> importer is pretty much useless to anyone because we don't really have a 
> perfect exported. 'hg export' is the best patch generator around, and it 
> is unable to produce a patch that will pass 'hg import --exact' in most 
> case.
>
> 'hg import --exact' does not exists in the vacum, people who attempt to 
> use it pretty much always try to use it in conjunction with 'hg export'. 

The name "export" was intended to put people in mind of the fact that they're
using a lossy operation that _leaves the confines of the system_, just like
File|Export in Word, Photoshop, whatever. You're leaving behind many of the
application-specific nuances and going into a portable but probably much more
limited format like .txt or .gif. Your pretty fonts and margins and footnotes
and whatnot are TOAST. Your layers and alpha channel and colorspace are TOAST.
"Import", similarly, is how you bring things into a system from a portable
format, possibly from another system, with possible further loss(!). And your
footnotes definitely won't reappear. Export|import is a thing lots of people
find useful, sure, but it's NOT why they exist.[1]

Which is why on the day --exact was introduced, it was well-known and intended that it would _abort on lots of patches_ due to the numerous ways that both standard and git diffs fail to fully represent Mercurial data/metadata (long before extra fields even entered the picture). And even if we fix the extra issue, we will still have a big set of corner cases that we will still want to abort on.

Look, git diffs can't even unambiguously represent filenames with spaces.
Nevermind representing reverse copies or criss-crossing renames. Nevermind
encodings and whitespace mangled by mailers. For these and a dozen other
reasons, there will ALWAYS be patches that break export|import. The point is to
have a way for that unavoidable breakage to not be silent. That way is called --
exact.

The way forward is probably to improve the docs. Suggested edits:

diff -r 5f95d6a70e9b mercurial/commands.py
--- a/mercurial/commands.py	Mon Feb 29 17:44:00 2016 -0600
+++ b/mercurial/commands.py	Mon Feb 29 19:57:29 2016 -0600
@@ -4595,7 +4595,7 @@
     ('', 'partial', None,
      _('commit even if some hunks fail')),
     ('', 'exact', None,
-Â Â Â Â Â _('apply patch to the nodes from which it was generated')),
+Â Â Â Â Â _('abort if patch would apply lossily')),
     ('', 'prefix', '',
      _('apply patch to subdirectory'), _('DIR')),
     ('', 'import-branch', None,
@@ -4635,8 +4635,9 @@
     If --exact is specified, import will set the working directory to
     the parent of each patch before applying it, and will abort if the
     resulting changeset has a different ID than the one recorded in
-Â Â Â Â the patch. This may happen due to character set problems or other
-Â Â Â Â deficiencies in the text patch format.
+Â Â Â Â the patch. This will guard against various ways that portable
+Â Â Â Â patch formats and mail systems might fail to transfer Mercurial
+Â Â Â Â data or metadata. See ':hg: bundle' for lossless transmission.
 
     Use --partial to ensure a changeset will be created from the patch
     even if some hunks fail to apply. Hunks that fail to apply will be



[1] The lossless counterparts, for anyone wondering, are known as "bundle" and
"unbundle"
--Â 
Mathematics is the supreme nostalgia of our time.