patch: be more tolerant with EOLs in binary diffs (issue2870) The only place where an trailing CR could be meaningful is in the "diff --git" line as part of a filename, and existing code already rule out this possibility. Extend the CR/LF filtering to the whole binary hunk.

patch: include file name in binary patch error messages $ hg import --no-commit ../mercurial_1915035238540490516.patch applying ../mercurial_1915035238540490516.patch abort: could not extract binary data Becomes: abort: could not extract "binary2" binary data

patch: display a nice error for invalid base85 data Before, import was terminating with a traceback. Now it says: $ hg import --no-commit ../bad.patch applying ../bad.patch abort: could not decode binary patch: bad base85 character at position 66

revset: fix adds/modifies/removes and patterns (issue3403) The fast path was triggered if the argument was not like "type:value", with type a known pattern type. This is wrong for several reasons: - path:value is valid for the fast path - '*' is interpreted as a glob by default and is not valid for fast path Fast path detection is now done after the pattern is parsed, and the normalized path is extracted for direct comparison. All this seems a bit complicated, it is tempting to drop the fast path completely. Also, the hasfile() revset does something similar (only check .files()), without a fast path. If the fast path is really that efficient maybe it should be used there too. Note that: $ log 'modifies("set:modified()")' is different from: $ log 'modifies("*")' because of the usual merge ctx.files()/status(ctx.p1(), ctx) differences. Reported by Steffen Eichenberg <steffen.eichenberg@msg-gillardon.de>

merge with i18n

i18n-pt_BR: synchronized with e3c7ca15cde2

merge with i18n

i18n-pt_BR: synchronized with 83622954b64d

largefiles: notice dirty large files in a subrepo Summary and commit use dirty() to check the status of a subrepository, so this overrides dirty() in the subrepo in the same manner as status() to check the large files instead of their standins. Previously, if only a large file was changed in a subrepo, summary in the top level repo would not report the subrepo was dirty and commit -S would report nothing changed. If any type of file was changed in the top repo and only a large file in the subrepo, commit -S would not commit the changes to the subrepo.

largefiles: fix status -S reporting of subrepos (issue3231) Wrapping the status command will only invoke overridestatus() and set the lfstatus field for the top level repository. Wrapping the status function is required to set the field on child repositories. Previously, status -S would report large files in a subrepo as '?' regardless of their actual states, and was inconsistent with what status would report from within that subrepo.