[PATCH] hg stable: fix issue 4748; origin of a renamed file is lost after merge

[Matt Mackall]

On Mon, 2015-07-13 at 19:43 +0200, Jeremy Parente wrote:
> # HG changeset patch
> # User jepa, system HG Jeremy Parente <jeremy.parente at oneaccess-net.com>
> # Date 1436802799 -7200
> #      Mon Jul 13 17:53:19 2015 +0200
> # Branch stable
> # Node ID b8c73f1f0d2e89aeb852f722bd3814112484d262
> # Parent  540cd0ddac49c1125b2e013aa2ff18ecbd4dd954
> hg: merge renamed file in c2 not modified in c1 treated as a copy (issue4748)
> 
> Change how to handle divergent that is a rename in c2 but unmodified in c1 to
> keep origin, we treat such case like a copy to be able to track diff between
> renamed file and original file.
> 
> diff -r 540cd0ddac49 -r b8c73f1f0d2e mercurial/copies.py
> --- a/mercurial/copies.py	Mon Jun 29 19:09:42 2015 -0700
> +++ b/mercurial/copies.py	Mon Jul 13 17:53:19 2015 +0200
> @@ -337,6 +337,12 @@
>                   # out files that have been renamed and then deleted
>                   renamedelete[of] = [f for f in fl if f in c1 or f in c2]
>                   renamedelete2.update(fl) # reverse map for below
> +            elif of in c1 and of not in c2:
> +                # fix: issue4748; not divergent, just matching renames else we
> +                # lost the origin information and can't anymore diff the new
> +                # file with an older revision where the file is named with the
> +                # original file name
> +                copy[fl[0]] = of

My guess is this is the wrong fix.. because the file shouldn't be
considered "divergent" in the first place: that should only happen when
both sides rename. But I think you're onto something here.

The huge set of test changes is also a bit terrifying. While I believe
it's possible that all of the tests were wrong and are now fixed, I'd
like to see some evidence that the changes were actually checked for
correctness.

(And Sean's right: the entire thing is whitespace-damaged.)

-- 
Mathematics is the supreme nostalgia of our time.