Thu, 26 Apr 2012 21:44:00 +0200 patch: include file name in binary patch error messages stable
Patrick Mezard <patrick@mezard.eu> [Thu, 26 Apr 2012 21:44:00 +0200] rev 16523
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
Sat, 21 Apr 2012 19:58:18 +0200 patch: display a nice error for invalid base85 data stable
Patrick Mezard <patrick@mezard.eu> [Sat, 21 Apr 2012 19:58:18 +0200] rev 16522
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
Thu, 26 Apr 2012 14:24:46 +0200 revset: fix adds/modifies/removes and patterns (issue3403) stable
Patrick Mezard <patrick@mezard.eu> [Thu, 26 Apr 2012 14:24:46 +0200] rev 16521
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>
(0) -10000 -3000 -1000 -300 -100 -30 -10 -3 +3 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip