Mercurial: Changelog

copies: calculate 'bothnew' from manifestdict.filesnotin() In the same spirit as the previous change, let's now calculate the 'bothnew' variable using manifestdict.filesnotin().5D

copies: replace _nonoverlap() by calls to manifestdict.filesnotin() Now that we have manifestdict.filesnotin(), we can write _nonoverlap() in terms of that method instead, enabling future speedups when filesnotin() gets optimized, and perhaps making the code a little clearer at the same time.

copies: move code into new manifestdict.filesnotin() method copies._computeforwardmissing() finds files in one context that is not in the other. Let's move this code into a new method on manifestdict, so m1.filesnotin(m2) can be optimized for various types of manifests (we expect more types of manifests soon).

subrepo: warn when adding already tracked files in gitsubrepo This follows normal Mercurial rules, and the message is lifted from workingctx.add(). The file is printed with abs() to be consistent with how it is printed in workingctx, even though that is inconsistent with how added files are printed in verbose mode. Further, the 'already tracked' notifications come after all of the files that are added are printed, like in Mercurial. As a side effect, we now have the reject list to return to the caller, so that 'hg add' exits with the proper code. It looks like an abort occurs if git fails to add the file. Prior to touching 'snake.python' in the test, this was the result of attempting to add the file after a 'git rm': fatal: pathspec 'snake.python' did not match any files abort: git add error 128 in s (in subrepo s) I'm not sure what happens when git is a deep subrepo, but the 'in s' and 'in subrepo s' from @annotatesubrepoerror are redundant here. Maybe we should stat the files before invoking git to catch this case and print out the prettier hg message? The other thing missing from workingctx.add() is the call to scmutil.checkportable(), but that would need to borrow the parent's ui object.

subrepo: don't exclude files in .hgignore when adding to git The previous test gave a false success because only an hg-ignored pattern was specified. Therefore match.files() was empty, and it fell back to the files unknown to git. The simplest fix is to always consider what is unknown to git, as well as anything specified explicitly. Files that are ignored by git can only be introduced by an explicit mention in match.files().