[PATCH 2 of 3] context: clarify why we don't compare file contents when nodeid differs

[Martin von Zweigbergk]

Good catch. Patch sent. Sorry about the trouble.

On Mon, Jan 25, 2016 at 2:42 PM Durham Goode <durham at fb.com> wrote:

>
>
> On 1/12/16 1:43 PM, Martin von Zweigbergk wrote:
> > # HG changeset patch
> > # User Martin von Zweigbergk <martinvonz at google.com>
> > # Date 1452632994 28800
> > #      Tue Jan 12 13:09:54 2016 -0800
> > # Node ID 228d5d4d70b304ad1afc7dcc5b7c6b366ea5d239
> > # Parent  f07b94c8bb3a311a47e91a2bc528f7d91145fc13
> > context: clarify why we don't compare file contents when nodeid differs
> >
> > diff --git a/mercurial/context.py b/mercurial/context.py
> > --- a/mercurial/context.py
> > +++ b/mercurial/context.py
> > @@ -140,15 +140,15 @@
> >                   added.append(fn)
> >               elif node2 is None:
> >                   removed.append(fn)
> > -            elif node2 != _newnode:
> > -                # The file was not a new file in mf2, so an entry
> > -                # from diff is really a difference.
> > +            elif self.rev() is not None:
> > +                # When comparing files between two commits, we save
> time by
> > +                # not comparing the file contents when the nodeids
> differ.
> > +                # Note that this means we incorrectly report a reverted
> change
> > +                # to a file as a modification.
> >                   modified.append(fn)
> >               elif flag1 != flag2:
> >                   modified.append(fn)
> >               elif self[fn].cmp(other[fn]):
> > -                # node2 was newnode, but the working file doesn't
> > -                # match the one in mf1.
> >                   modified.append(fn)
> >               else:
> >                   clean.append(fn)
> This seems to contain a code change ( "node2 != _newnode" becomes
> "self.rev() is not None").  Was that intentional?  It doesn't seem to
> match the new comment, so I get the feeling it wasn't.
>
> I only noticed because it causes more cases to fall through to the cmp()
> call below, which triggers some unusual remotefilelog fetch activity.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20160126/a682b55e/attachment.html>