"Mark J. Nelson" <Mark.J.Nelson at Sun.COM> writes: > Why do > >> for fname in wctx.files() >> if fname not in wctx: >> continue > > instead of > >> for fname in wctx.modified() + wctx.added() > > ? Is the sort() implied by files() important? (The "fname not in" > clause is intended to exclude files removed in the working context, > right?)
Yes, that's the intent. > Per this comment in the bug report: > >> Note that the issue with git-formatted diffs only occurs if the >> destination file already existed *at the time you did a copy or >> rename over it*, not (to the best of my knowledge), if a file has >> ever previously existed by that name. > > ...then shouldn't you also be excluding removals from the "fname in p" > part of: I don't think so, no. If it were removed in a change prior to the working copy, it wouldn't be in the manifest of the parent node. >> if rn: >> for p in pctxs: >> if fname in p: >> ret.append((rn[0], fname)) > > Otherwise, if a versioned file was removed in both parent changesets, > and you copy/rename onto it, you'll return it incorrectly, right? I don't think so, no, but I will make sure I test that explicitly. > Also, don't you want a "break" after the ret.append here? > It was missing intentionally, for the case of an uncommitted merge, but as we refuse them anyway, I could do that, yes. -- Rich
