Thu, 10 Nov 2011 11:00:02 -0600 merge with i18n stable
Matt Mackall <mpm@selenic.com> [Thu, 10 Nov 2011 11:00:02 -0600] rev 15470
merge with i18n
Tue, 08 Nov 2011 17:09:48 +0100 rebase: ensure target is not taken as external (issue3085) stable
Stefano Tortarolo <stefano.tortarolo@gmail.com> [Tue, 08 Nov 2011 17:09:48 +0100] rev 15469
rebase: ensure target is not taken as external (issue3085) This could happen in specific situations in which 'target' was selected as external and used for p1 _and_ p2.
Thu, 10 Nov 2011 10:59:03 -0600 merge with i18n
Matt Mackall <mpm@selenic.com> [Thu, 10 Nov 2011 10:59:03 -0600] rev 15468
merge with i18n
Wed, 09 Nov 2011 19:01:10 +0100 i18n: merge with stable
Martin Geisler <mg@lazybytes.net> [Wed, 09 Nov 2011 19:01:10 +0100] rev 15467
i18n: merge with stable
Wed, 09 Nov 2011 18:58:17 +0100 i18n-da: add new strings from Mercurial 2.0 stable
Martin Geisler <mg@lazybytes.net> [Wed, 09 Nov 2011 18:58:17 +0100] rev 15466
i18n-da: add new strings from Mercurial 2.0
Wed, 09 Nov 2011 18:26:54 +0100 i18n-ru: fix translation of --logfile (issue3095) stable
Martin Geisler <mg@lazybytes.net> [Wed, 09 Nov 2011 18:26:54 +0100] rev 15465
i18n-ru: fix translation of --logfile (issue3095)
Sun, 06 Nov 2011 23:35:33 +0100 rebase: treat nullmerge as a special case in rebasestate (issue3046) stable
Stefano Tortarolo <stefano.tortarolo@gmail.com> [Sun, 06 Nov 2011 23:35:33 +0100] rev 15464
rebase: treat nullmerge as a special case in rebasestate (issue3046) When storing/restoring a nullmerge (-2), a 'standard' conversion was made and an existing changeset was wrongly used. Nullmerge should instead be treated as a special case.
Tue, 08 Nov 2011 21:31:39 +0100 graft: mark a string for translation stable
Stefano Tortarolo <stefano.tortarolo@gmail.com> [Tue, 08 Nov 2011 21:31:39 +0100] rev 15463
graft: mark a string for translation
Wed, 09 Nov 2011 16:55:59 -0800 mdiff/patch: fix bad hunk handling for unified diffs with zero context stable
Nicolas Venegas <nvenegas@atlassian.com> [Wed, 09 Nov 2011 16:55:59 -0800] rev 15462
mdiff/patch: fix bad hunk handling for unified diffs with zero context Prior to this patch "hg diff -U0", i.e., zero lines of context, would output hunk headers with a start line one greater than what GNU patch and git output. Guido van Rossum documents the unified diff format[1] as having a start line value "one lower than one would expect" for zero length hunks. Comparing the behaviour of the three systems prior to this patch in transforming c1 c3 to c1 c2 c3 - GNU "diff -U0" reports the hunk as "@@ -1,0 +2 @@" - "git diff -U0" reports the hunk as "@@ -1,0 +2 @@" - "hg diff -U0" reports the hunk as "@@ -2,0 +2,1 @@" After this patch, "hg diff -U0" reports "@@ -1,0 +2,1 @@". Since "hg export --config diff.unified=0" outputs zero-context unified diffs, "hg import" has also been updated to account for start lines one less than expected for zero length hunk ranges. [1]: http://www.artima.com/weblogs/viewpost.jsp?thread=164293
Tue, 08 Nov 2011 17:08:58 +0100 convert/bzr: correctly handle divergent nested renames (issue3089) stable
Patrick Mezard <pmezard@gmail.com> [Tue, 08 Nov 2011 17:08:58 +0100] rev 15461
convert/bzr: correctly handle divergent nested renames (issue3089) With renames like: a -> b a/c -> a/c We were ignoring or duplicating the second one instead of leaving files unchanged or moving them to their proper destination only. To avoid this, we process the files in reverse lexicographic order, from most to least specific change, and ignore files already processed. v2: - Add a test - Change "reverse=1" into "reverse=True"
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip