The "r" option for this feature was copied into Mercurial from
crecord, but the actual implementation never made it into hg until
now. It's a moderately useful feature that allows the user to edit the
patch in a text editor before comitting it for good.
This requires a test, so we must also enable a corresponding testing
'R' option that skips the confirmation dialogue. In addition, we also
need a help text for the editor when reviewing the final patch.
As for why this is a useful feature if we can already edit hunks in an
editor, I would like to offer the following points:
* editing hunks does not show the entire patch all at once
** furthermore, the hunk "tree" in the TUI has no root that could be
selected for edition
* it is helpful to be able to see the entire final patch for
confirmation
** within this view, the unselected hunks are hidden, which is
visusally cleaner
** this works as a final review of the complete result, which is
a bit more difficult to do conceptually via hunk editing
* this feature was already in crecord, so it was an oversight to
not bring it to core
* it works and is consistent with editing hunks
SyntaxError is the class representing syntax errors in Python code. We should
use a dedicated exception class for our needs. With this change, unnecessary
re-wrapping of SyntaxError can be eliminated.
I let this slip in the [ui] section during the review, as far as I understand we
don't plan to actually support customisation of the output on we are happy with
our choice. The option are just here to help people tests various options so we
can decide which one we'll actually use.
I'm moving the config option in the experimental section to make this clearer
and avoid making them part of the public API by mistake.
A bigger picture is the ability to be delete an arbitrary marker form the
repo's obsstore. This is a useful debug ability and it needs a way to indentify
the marker one wants to delete. Having a marker's index provides such an
ability.
Before this change, warnings were interspersed with (and easily drowned out by)
status messages.
API:
abstractsubrepo.removefiles has an extra argument warnings,
into which callees should append their warnings.
Note: Callees should not assume that there will be items in the list,
today, I'm lazily including any other subrepos warnings, but
that may change.
cmdutil.remove has an extra optional argument warnings,
into which it will place warnings.
If warnings is omitted, warnings will be reported via ui.warn()
as before this change (albeit, after any status messages).
Rather than draw an edge all the way to the bottom of the graph, make it
possible to end an edge to parents that are not part of the graph early on.
This results in a far cleaner graph.
Any edge type can be set to end early; set the ui.graphstyle.<edgetype>
parameter to the empty string to enable this.
For example, setting the following configuration:
[ui]
graphstyle.grandparent = :
graphstyle.missing =
would result in a graph like this:
o changeset: 32:d06dffa21a31
|\ parent: 27:886ed638191b
| : parent: 31:621d83e11f67
| :
o : changeset: 31:621d83e11f67
|\: parent: 21:d42a756af44d
| : parent: 30:6e11cd4b648f
| :
o : changeset: 30:6e11cd4b648f
|\ \ parent: 28:44ecd0b9ae99
| ~ : parent: 29:cd9bb2be7593
| /
o : changeset: 28:44ecd0b9ae99
|\ \ parent: 1:6db2ef61d156
| ~ : parent: 26:7f25b6c2f0b9
| /
o : changeset: 26:7f25b6c2f0b9
|\ \ parent: 18:1aa84d96232a
| | : parent: 25:91da8ed57247
| | :
| o : changeset: 25:91da8ed57247
| |\: parent: 21:d42a756af44d
| | : parent: 24:a9c19a3d96b7
| | :
| o : changeset: 24:a9c19a3d96b7
| |\ \ parent: 0:e6eb3150255d
| | ~ : parent: 23:a01cddf0766d
| | /
| o : changeset: 23:a01cddf0766d
| |\ \ parent: 1:6db2ef61d156
| | ~ : parent: 22:e0d9cccacb5d
| | /
| o : changeset: 22:e0d9cccacb5d
|/:/ parent: 18:1aa84d96232a
| : parent: 21:d42a756af44d
| :
| o changeset: 21:d42a756af44d
| |\ parent: 19:31ddc2c1573b
| | | parent: 20:d30ed6450e32
| | |
+---o changeset: 20:d30ed6450e32
| | | parent: 0:e6eb3150255d
| | ~ parent: 18:1aa84d96232a
| |
| o changeset: 19:31ddc2c1573b
| |\ parent: 15:1dda3f72782d
| ~ ~ parent: 17:44765d7c06e0
|
o changeset: 18:1aa84d96232a
parent: 1:6db2ef61d156
parent: 15:1dda3f72782d
The default configuration leaves all 3 types set to |.
This is part of the work towards moving smartlog upstream; currently smartlog
injects extra nodes into the graph to indicate grandparent relationships (nodes
elided).
The next patch will add another postexec command: chdir, which can be used
together with unlink. This patch changes the option type of --daemon-postexec
from string to list to accept multiple commands. The error message of invalid
--daemon-postexec value is also changed to include the actual invalid value.
The 'm.always()' check was needed for when a path to 'sub1' is given, and 'sub1'
contains a subrepo itself. But that also caused the automatic recursion when no
path was given. Instead, force -S when printing a subrepo if the subpath is an
exact match (which will unconditionally recurse once in the nested subrepo).
This is the simplest workaround for the issue of the ordering of revset, which
is that the expression "x or y" takes over the ordering specified by the input
set (or the left-hand-side expression.) For example, the following expression
A & (x | y)
will be evaluated as if
(A & x) | (A & y)
That's wrong because revset has ordering. I'm going to fix this problem in
the revset module, but that wouldn't fit to stable. So, this patch just works
around the common log cases.
Since this change might have some impact on performance, it is enabled only
if the expression built from log options has ' or ' operation.
During merge, added (from one perspective) file can be reported as "modified".
To work around that, revert was testing if modified file were present in the
parent manifest and marking them as "added" in this case. However, we should be
checking against the target revision manifest instead. Otherwise see file as
"newly added" even if they exist in the target revision.
That revert behavior regressed in 3657ae7519b7.
This backs out changeset fd794e885a9e9.
There are some extra fields that absolutely should not be preserved, like the
convert_revision field introduced by the convert and hgsubversion extensions.
The problem with extensions blacklisting certain extra fields is that they
might not be enabled at the time the amend is performed.
In the long run we probably want separately marked transferable and
non-transferable extra fields, but for now restore the old Mercurial 3.6
behavior.
The largefiles extension needs to set lfstatus for this status call. Otherwise,
if a missing largefile is explicitly named, a confusing message is issued that
says the largefile wasn't found, followed by another that says nothing changed.
To describe the bug this fix is addressing, one can do
``$ hg status -T "{label('red', path)}\n" --color=debug``
and observe that the label is not applied before my fix and applied with it.
This further centralizes the handling of bookmark storage, and will
help get some lingering bookmarks business out of localrepo. Right
now, this change implies reading of the active bookmark to also imply
reading all bookmarks from disk - for users with many many bookmarks
this may be a measurable performance hit. In that case, we should
migrate bmstore to be able to lazy-read its properties from disk
rather than having to eagerly read them, but I decided to avoid doing
that to try and avoid some potentially complicated filecache decorator
issues.
This doesn't move the logic for writing the active bookmark into a
transaction, though that is probably the correct next step. Since the
API probably needs to morph a little more, I didn't bother marking
bookmarks.{activate,deactivate} as deprecated yet.
Expose afterresolvedstates to allow graft and similar to
suggest a message when resolving results in no unresolved
files.
If there isn't a matching state in afterresolvedstates,
then if verbose, suggest commiting.
0f01b8ad724c changed showpatch to use ctx's more, but it accidentally passed
prev as a context and node as a binary string, when both should be passed as
binary strings (since diffordiffstat tries to resolve them via repo[X]).
This affected hggit since the existing ctx belongs to the git overlay, but the
resolved context (from the repo[X] resolution) should belong to the main repo.
This broke a test because it tried to look in the git repo for data that didn't
exist.
This feels like a deeper issue in hggit somewhere, but the fix is here trivial and
obviously more correct
Instead of blindly trusting the user's experimental.crecord, we use checkcurses
to abstract that logic so that we can handle the case where python was not
built with curses.
Previously, we could be calling os.utime or os.chflags (via shutil.copystat) on
a symlink. These functions dereference symlinks, so this would have caused the
timestamp of the target to be set. On a read-only or similarly weird
filesystem, this might cause an exception to be raised.
This is pretty hard to test because conjuring up a read-only filesystem for
test purposes is non-trivial.
It made output order unpredictable because two separate buffers are flushed
individually. Let's use a thin wrapper that just sends close() to black hole.
It was introduced at fa80944106df, where "template" argument could be a file
object. After that, 426525670e45 added "len(template)", so "template" must be
a string now. Therefore, "fp != template" should always be True.
It seems fa80944106df was intended to work around a bug in TortoiseHg, and
I'm sure I've fixed it completely in TortoiseHg source.
https://selenic.com/pipermail/mercurial-devel/2011-February/028467.html
Because makefileobj() duplicates or wraps stdout, "fp != sys.stdout" didn't
work correctly. Python doc states that special file objects are named in the
form '<...>', and absolute filenames should never start with '<', we can
ignore names start with '<'. We can't test fp.fileno() because fp may be a
command-server channel.
https://docs.python.org/2.7/library/stdtypes.html#file.name
In the test output, "exporting patch:" line is printed after patch content.
This is caused by fdopen() and will be fixed by the subsequent patch.
Before this patch, external editor process for the commit log can't
view some in-memory changes (especially, of dirstate), because they
aren't written out until the end of transaction (or wlock).
This causes unexpected output of Mercurial commands spawned from that
editor process.
To make in-memory changes visible to external editor process, this
patch does:
- write (or schedule to write) in-memory dirstate changes, and
- set HG_PENDING environment variable, if:
- a transaction is running, and
- there are in-memory changes to be visible
"hg diff" spawned from external editor process for "hg qrefresh"
shows:
- "changes newly imported into the topmost" before ab68b153ce34(*)
- "all changes recorded in the topmost by refreshing" after this patch
(*) ab68b153ce34 changed steps invoking editor process
Even though backward compatibility may be broken, the latter behavior
looks reasonable, because "hg diff" spawned from the editor process
consistently shows "what changes new revision records" regardless of
invocation context.
In fact, issue4378 itself should be resolved by b46029eb5b29, which
made 'repo.transaction()' write in-memory dirstate changes out
explicitly before starting transaction. It also made "hg qrefresh"
imply 'dirstate.write()' before external editor invocation in call
chain below.
- mq.queue.refresh
- strip.strip
- repair.strip
- localrepository.transaction
- dirstate.write
- localrepository.commit
- invoke external editor
Though, this patch has '(issue4378)' in own summary line to indicate
that issues like issue4378 should be fixed by this.
BTW, this patch adds '-m' option to a 'hg ci --amend' execution in
'test-commit-amend.t', to avoid invoking external editor process.
In this case, "unsure" states may be changed to "clean" according to
timestamp or so on. These changes should be written into pending file,
if external editor invocation is required,
Then, writing dirstate changes out breaks stability of test, because
it shows "transaction abort!/rollback completed" occasionally.
Aborting after editor process invocation while commands below may
cause similar instability of tests, too (AFAIK, there is no more such
one, at this revision)
- commit --amend
- without --message/--logfile
- import
- without --message/--logfile,
- without --no-commit,
- without --bypass,
- one of below, and
- patch has no description text, or
- with --edit
- aborting at the 1st patch, which adds or removes file(s)
- if it only changes existing files, status is checked only for
changed files by 'scmutil.matchfiles()', and transition from
"unsure" to "normal" in dirstate doesn't occur (= dirstate
isn't changed, and written out)
- aborting at the 2nd or later patch implies other pending
changes (e.g. changelog), and always causes showing
"transaction abort!/rollback completed"
New ui.graphnodetemplate option allows us to colorize a node symbol by phase
or branch,
[ui]
graphnodetemplate = {label('graphnode.{phase}', graphnode)}
[color]
graphnode.draft = yellow bold
or use a variety of unicode emoji characters, and so on. (You'll need less-481
to display non-BMP unicode character.)
[ui]
graphnodetemplate = {ifeq(obsolete, 'stable', graphnode, '\xf0\x9f\x92\xa9')}
This provides a default node symbol. Tests will be added later.
"showparents" variable is renamed to "wpnodes" to avoid confusion with the
existing showparents() function.
