[PATCH] copies: optimize forward copy detection logic for rebases

[Augie Fackler]

On Fri, Feb 05, 2016 at 12:53:17PM -0800, Martin von Zweigbergk wrote:
> On Fri, Feb 5, 2016 at 12:51 PM, Augie Fackler <raf at durin42.com> wrote:
> > On Fri, Feb 05, 2016 at 11:48:10AM -0800, Durham Goode wrote:
> >> # HG changeset patch
> >> # User Durham Goode <durham at fb.com>
> >> # Date 1454701571 28800
> >> #      Fri Feb 05 11:46:11 2016 -0800
> >> # Node ID 6eca9fcd1a9cce2f07a212a9c0eaf05dacd082df
> >> # Parent  01a5143cd25f285f8c745a92986cd7186bb32c90
> >> copies: optimize forward copy detection logic for rebases
> >
> > This looks great to me. I've spent a few minutes trying to puzzle out
> > a case where it would be wrong, and I can't. As such: queued!
>
> How about when b is a merge?

I thought about that, but if a file was newly copied in the merge,
wouldn't we have previously walked over a revision in which it was
copied, or else it'd be in the changed files list in the merge?

(I could be wrong, the reasoning here is somewhat subtle.)