Formerly RST blocks were formatted without a trailing newline, which
wasn't particularly helpful. Now everything that comes back from the
formatter has a trailing newline so remove all the extra ones added by
users.
- move the obscure parts into the verbose help
- drop confusing references to "remove from repository" / "not remove
from history"
- add mention of hg forget
This adds a subset of the 'simple table' support from RST to allow
formatting of options lists through RST. Table columns are
automatically sized based on contents, with line wrapping in the last
column.
Corresponds to -C of the update command.
It's much more convenient to use:
$ hg revert -aC
than having to type
$ hg revert -a --no-backup
I think the 'no-backup' case is a frequent use case.
Introducing short option -C here fits with the muscle memory we have from
'hg update -C', which is described there as "discard uncommitted changes
(no backup)".
Before, the help text said that Mercurial would assume 'yes' for all
prompts, but this is confusing since many prompts don't have any 'yes'
choice. It now more accurately describes what will happen.
BEFORE:
$ hg revert
abort: no files or directories specified
(use --all to discard all changes)
AFTER:
Uncommitted changes (using --all *will* nuke edits):
$ hg revert
abort: no files or directories specified
(uncommitted changes, use --all to discard all changes)
Clean working directory (using --all won't discard anything):
$ hg revert
abort: no files or directories specified
(use --all to revert all files)
and give a more precise hint for how to revert such a file
I'm using the term 'revision' instead of 'changeset' in this change to be
consistent with the REV we use in the synopsis.
and explicitly warn about uncommitted changes
Examples:
BEFORE:
$ hg par -q
7:e81a2efd53d4
$ hg revert -r 2
abort: no files or directories specified
(use --all to discard all changes)
AFTER:
Clean working directory (revert can be easily undone, no edits to be lost):
$ hg revert -r 2
abort: no files or directories specified
(use --all to revert all files, or 'hg update 2' to update)
Uncommitted changes (revert --all *does* discard edits and is pretty hard to
undo or even impossible if --no-backup is specified):
$ hg revert -r 2
abort: no files or directories specified
(uncommitted changes, use --all to discard all changes, or 'hg update 2' to update)
BEFORE:
$ hg revert
abort: no files or directories specified
(use --all to discard all changes)
AFTER:
$ hg revert
abort: no files or directories specified
(uncommitted merge, use --all to discard all changes, or 'hg update -C .' to abort the merge)
BEFORE:
$ hg revert
abort: no files or directories specified
(use --all to revert all files)
AFTER:
$ hg revert
abort: no files or directories specified
(use --all to discard all changes)
The most appropriate context is not always clearly defined. The obvious cases:
For working directory commands, we use None
For commands (eg annotate) with single revs, we use that revision
The less obvious cases:
For commands (eg status, diff) with a pair of revs, we use the second revision
For commands that take a range (like log), we use None
This feature is more a way to test patching without a working directory than
something people asked about. Adding a --rev option to specify the parent patch
revision would make it a little more useful.
What this change introduces is patch.repobackend class which let patches be
applied against repository revisions. The caller must supply a filestore object
to receive patched content, which can be turned into a memctx with
patch.makememctx() helper.
