[PATCH STABLE] transplant: handle non-empty patches doing nothing (issue2806)

Greg Ward greg at gerg.ca
Wed Aug 1 18:57:35 CDT 2012


On 7/31/12, Patrick Mezard <patrick at mezard.eu> wrote:
> # HG changeset patch
> # User Patrick Mezard <patrick at mezard.eu>
> # Date 1343749172 -7200
> # Branch stable
> # Node ID 3fc1bd37e77731208359259575ac6ed06726189b
> # Parent  7d2967de2c04489f9ce64308eb39d8a55d66af7c
> transplant: handle non-empty patches doing nothing (issue2806)
>
> If patch.patch() reports patched files when applying a changeset and the
> following commit says nothing changed, transplant used to abort with a
> RuntimeError, assuming something went wrong with patching.

>          if not n:
> -            self.ui.warn(_('%s: empty changeset') % revlog.hex(node))
> +            self.ui.warn(_('skipping emptied changeset %s\n') %
> short(node))
>              return None

<bikeshedding>
How about

  _('changeset %s resulted in no change: skipping it\n')
    % node.short(node)

?
</bikeshedding>

On 01 August 2012, Patrick Mézard said:
> Actually it can still drop changes on the floor, when changing file
> modes on Windows for instance. Note that hg import also silently
> discards such changes. Not sure what to do at this point, maybe try
> reimplementing with patchrepo + update.

You mean with your patch, mode changes on Windows will be dropped? Or
the old code would do that? The old code deliberately crashes rather
than silently drop changesets; I'm not sure if dropping valid
meaningful changesets -- even with a warning -- really makes things
better.

Anyways, if your patch (re-)introduces the possibility of transplant
dropping changes, I'm *slightly* opposed to it. The warning makes it
tolerable, but still. If the possibility was already there, I have no
objection.

       Greg
-- 
Greg Ward                                http://www.gerg.ca/
What the hell, go ahead and put all your eggs in one basket.


More information about the Mercurial-devel mailing list