C?dric Duval <cedricduval@free.fr> [Mon, 22 Jun 2009 15:48:08 +0200] rev 584
extensions: improve the consistency of synopses
Trying as much as possible to consistently:
- use a present tense predicate followed by a direct object
- verb referring directly to the functionality provided
(ie. not "add command that does this" but simple "do that")
- keep simple and to the point, leaving details for the long help
(width is tight, possibly even more so for translations)
Thanks to timeless, Martin Geisler, Rafael Villar Burke, Dan Villiom
Podlaski Christiansen and others for the helpful suggestions.
[ original upstream message ]
Christian Ebert <blacktrash@gmx.net> [Sun, 21 Jun 2009 23:17:37 +0100] rev 583
Merge with stable
C?dric Duval <cedricduval@free.fr> [Sat, 20 Jun 2009 20:57:13 +0200] rev 582
help: remove per-extension paragraph on how to enable it
The central place to find this information is the "extensions" help topic.
[ original upstream message ]
Christian Ebert <blacktrash@gmx.net> [Thu, 18 Jun 2009 12:45:39 +0100] rev 581
(0.9.2compat) concise help title
Christian Ebert <blacktrash@gmx.net> [Thu, 18 Jun 2009 12:43:19 +0100] rev 580
(stable) merge
Christian Ebert <blacktrash@gmx.net> [Thu, 18 Jun 2009 01:21:26 +0100] rev 579
Concise help title
Christian Ebert <blacktrash@gmx.net> [Mon, 15 Jun 2009 11:10:15 +0100] rev 578
Merge with stable
Patrick Mezard <pmezard@gmail.com> [Mon, 15 Jun 2009 00:03:26 +0200] rev 577
Add patch.eol to ignore EOLs when patching (issue1019)
The intent is to fix many issues involving patching when win32ext is enabled.
With win32ext, the working directory and repository files EOLs are not the same
which means that patches made on a non-win32ext host do not apply cleanly
because of EOLs discrepancies. A theorically correct approach would be
transform either the patched file or the patch content with the
encoding/decoding filters used by win32ext. This solution is tricky to
implement and invasive, instead we prefer to address the win32ext case, by
offering a way to ignore input EOLs when patching and rewriting them when
saving the patched result.
[ original upstream message ]
Christian Ebert <blacktrash@gmx.net> [Tue, 09 Jun 2009 22:42:39 +0200] rev 576
Merge with stable
Christian Ebert <blacktrash@gmx.net> [Tue, 09 Jun 2009 22:42:23 +0200] rev 575
(0.9.2compat) update doc strings and help
Christian Ebert <blacktrash@gmx.net> [Tue, 09 Jun 2009 22:32:14 +0200] rev 574
(0.9.2compat) improve English; from stable
timeless <timeless@gmail.com> [Tue, 09 Jun 2009 09:25:34 -0400] rev 573
keyword: improve English
[ original upstream message ]
Christian Ebert <blacktrash@gmx.net> [Tue, 09 Jun 2009 10:34:01 +0200] rev 572
Merge with stable
Matt Mackall <mpm@selenic.com> [Mon, 08 Jun 2009 18:14:44 -0500] rev 571
merge: allow merging going backwards
New behavior is generally superior and more correct, except possibly
with regards to missing files. hg up . is now effectively a no-op,
which is probably the desired behavior for people expecting to move to
tip, but may surprise people who were expecting deleted files to
reappear.
case 1: update to .
a-w -> a-w
classic: ancestor a
missing recreated right?
rmed recreated WRONG
added forgotten WRONG
changed preserved RIGHT
conflicted can't happen
backward merge: ancestor a (NO EFFECT)
missing missing wrong?
rm'ed rm'ed RIGHT
added preserved RIGHT
changed preserved RIGHT
conflicted can't happen
case 2: update to ancestor of .
a-b-w -> b-w
\
a
classic: ancestor a
missing recreated right?
rmed recreated wrong?
added forgotten wrong?
changed preserved RIGHT
conflicted preserved wrong?
backwards merge: ancestor b
missing missing or conflict right?
rm'ed missing or conflict right?
changed preserved RIGHT
conflicted merge RIGHT
added preserved right?
[ original upstream message ]
Christian Ebert <blacktrash@gmx.net> [Sun, 07 Jun 2009 19:25:53 +0200] rev 570
(stable) merge