Each check is moved under the code handling the relevant option, and
a new one is added for --create. This fixes duplicated entries being
added to the queues list.
Before this bugfix a file whose changes were entirely recorded was still
considered modified by "hg status".
Note: the test must use hg record -l/--logfile, because this is not
reproducible with hg record -m/--message.
It might sound like a good idea to use record to filter changes when merging.
If someone attemps this, it's better to tell her "no" right ahead, before the
patch generation/line selection, so she does not spend time doing it just to
receive a red light after that (sometimes rather long) process.
note: expansion of config variables must be handled on a case-by-case basis
because they can contain arbitrary data that may not be desirable to expand.
I routinely want to use `hg addrem` and then fix up missed renames
manually using `hg mv -A`. This patch allows me to record such
renames from a source in state R to a target in state A.
Compare this to --force which allows anything to be pushed. With --new-branch,
only changesets to named branches not present on the and changesets not
introducing additional heads on existing branches are allowed.
Developed by
Henrik Stuart <henrik.stuart@edlund.dk>
Sune Foldager <cryo@cyanite.org>
bisect: clarify None return
bundle: return 1 on no changes
clone: return result code
copy: limit errors to 0/1
commit: return 1 on no changes
forget: return 1 on errors
grep: return 1 if no match found
remove: return 1 on errors
resolve: return 1 if something fails to resolve
rollback: return 1 if no rollback data
Currently running 'hg rename --after foo.txt bar.typo' is a silent no-op. This patch adds a warning. It also updates the copy and rename tests.
No actual functionality is changed.
fixes issue 1822
From RFC 5322:
an optional reply-to field MAY also be included, which contains the field
name "Reply-To" and a comma-separated list of one or more addresses.
[...]
When the "Reply-To:" field is present, it indicates the address(es) to which
the author of the message suggests that replies be sent. In the absence of
the "Reply-To:" field, replies SHOULD by default be sent to the mailbox(es)
specified in the "From:" field unless otherwise specified by the person
composing the reply.
Reply-To addresses may be specified either via command line with --reply-to
or via the 'email' or 'patchbomb' sections of the config file.
When converting non-local repositories, scanning changed paths before
retrieving data can be almost as slow as retrieving the data itself, thanks to
HTTP calls overhead.
