This behavior regressed as part of the paths API refactoring. Previous
behavior was to accept "default-push" without "default" defined. Current
behavior aborts with "default repository not configured!." This patch
restores the old behavior and adds test coverage for the scenario, which
was absent before.
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"
The home of 'Abort' is 'error' not 'util' however, a lot of code seems to be
confused about that and gives all the credit to 'util' instead of the
hardworking 'error'. In a spirit of equity, we break the cycle of injustice and
give back to 'error' the respect it deserves. And screw that 'util' poser.
For great justice.
I almost introduced a bug around this code by accidentally mutating a default
argument. There's no reason for these to exist.
It is OK to not assign {} to environ in ui.system because util.system knows how
to deal with that.
The previous paths API code always fell back to the default path. This
was wrong because if a requested path doesn't exist, that should error.
Only if no path was requested should we fall back to the default.
As part of implementing the test case for issue 4796, it was discovered
that the "repository does not exist" error message raised by
localrepository.__init__ wasn't being seen because the paths API
validates paths before localrepository.__init__ was being called.
The exception and error message from localrepository.__init__ has
been introduced to getpath(). This necessitated rewriting
expandpath() both to catch the exception and to have proper
default fallback.
This code is more complicated than I'd like. But making all tests pass
was a big chore. As more code moves to getpath(), there will likely be
opportunities to improve things a bit.
Hard coding the '.hg' path in the paths class made it difficult for the hggit
extension to pull from gitrepos.
This patch moves the logic out to it's own function so extensions can add
additional checks to what is a valid path (i.e. a git repo is valid when hggit
is enabled).
Currently, we treat "default" and "default-push" as separate paths,
even though they are the same logical entity but with different paths
for different operations. Because they are the same entity and
because we will eventually be implementing an official mechanism
for declaring push URLs for paths, we establish a "pushloc" attribute
on path instances. We populate this attribute on the "default" path
with the "default-push" value, if present. This will enable
consumers stop referencing "default-push" which will make their code
simpler.
ui.expandpath() has code for recognizing URLs or local filesystem
paths. Our goal is to use ``path`` class instances everywhere a path
is represented.
Changing ui.expandpath() to return path instances is a lot of work.
Our goal is to slowly marginalize it by moving logic into the paths
API and to convert callers to the paths API.
Many callers of ui.expandpath() pass in a value that could be a
local filesystem path or URI. We move the detection of these strings
from ui.expandpath() to paths.getpath() and path.__init__(). To do
this properly in a way that is compatible with future callers, we
need to parse the "#branch" syntax out of locations. This is a bit
complicated, but it is necessary.
The code for URL parsing is essentially a copy of hg.parseurl().
Once all consumers are speaking the paths API, it is likely that
this function won't be called any more and it can be deleted.
Python 2.6 introduced the "except type as instance" syntax, replacing
the "except type, instance" syntax that came before. Python 3 dropped
support for the latter syntax. Since we no longer support Python 2.4 or
2.5, we have no need to continue supporting the "except type, instance".
This patch mass rewrites the exception syntax to be Python 2.6+ and
Python 3 compatible.
This patch was produced by running `2to3 -f except -w -n .`.
There were consistent test failures in test-bad-extension.t, because Windows
buffers stderr when redirected to a file (per the comment in ui.write_err()).
That resulted in failures like this:
--- c:/Users/Matt/Projects/hg/tests/test-bad-extension.t
+++ c:/Users/Matt/Projects/hg/tests/test-bad-extension.t.err
@@ -23,11 +23,11 @@
Traceback (most recent call last):
Exception: bit bucket overflow
*** failed to import extension badext2: No module named badext2
- Traceback (most recent call last):
- ImportError: No module named badext2
hg help [-ec] [TOPIC]
show help for a given topic or a help overview
+ Traceback (most recent call last):
+ ImportError: No module named badext2
show traceback for ImportError of hgext.name if debug is set
(note that --debug option isn't applied yet when loading extensions)
Instead of inserting another flush immediately after the print, to go along with
the one recently added prior to the print (see 3cd72de3be66), funnel the output
through ui.write_err(). The flush prior to printing the traceback only mentions
that stdout needs to be flushed, and only stderr needs to be flushed after
printing the traceback. ui.write_err() does both for us without needing to
redocument the quirky Windows behavior. It will also clear any progress bar.
The ui object can take care of its progress object logic by itself.
test-subrepo-recursion is modified because it is a bit sensitive to the "no
progress bar" default. It will become unnecessary in the next step when
progress will be on by default in core.
The use of a singleton for all of progress handling is debatable (because
config may vary). However this is how the extension has been doing it so far.
We move that code into the ui module because this is where is should belong when
progress is moved into core.
When the progress extension is not enabled, each call to 'ui.progress' used to
issue a debug message. This results is a very verbose output and often redundant
in tests. Dropping it makes tests less volatile to factor they do not meant to
test.
We had to alter the sed trick in 'test-rename-merge2.t'. Sed is used to drop all
output from a certain point and hidding the progress output remove its anchor.
So we anchor on something else.
ui.plain() is supposed to disable config options that change the UI to the
detriment of scripts. As the test demonstrates, revset aliases can actually
override builtin ones, just like command aliases. Therefore I believe this is a
bugfix and appropriate for stable.
We want to capture hooks output during bundle2 processing. For this purpose we
introduce a new 'subproc' argument to 'ui.pushbuffer'. When set, the output of
sub process created through 'ui.system' will be captured in the buffer too.
This will be used in the next changeset.
Revision 7fbf0ef28408 ('graft: record intermediate grafts in extras') introduced
'intermediate-source' extra which refers to the closest graft source.
As 'intermediate-source' extra provides more detailed information about the source
changeset than 'source' one, it is better to prefer the first one to use as a
value of HGREVISION environment variable for an editor.
Many have long wanted for paths to have expanded functionality and
flexibility.
In order to make that transition possible, we need to start
representing paths as something more than simple strings.
This patch introduces two classes:
1) "path" for representing a single path instance
2) "paths" for representing a collection of "paths"
Since we don't like patches that introduce new code without any
consumers, we convert ui.expandpath() to use the new APIs internally.
Upcoming patches will start exposing "path" instances to consumers
that currently interface with string paths.
The new "paths" attribute of ui is populated from config data the first
time it is accessed. Since it isn't updated when the configs are
modified, this could lead to some inaccurate caching behavior. It
shouldn't be an issue, as paths information is typically not accessed
until command dispatch, which occurs after the repository config
and extensions have been loaded. Time will tell if we need to refresh
paths information when the underlying config changes.
This change is intended to avoid future problem of data corruption under
command server. out=ui.fout is mandatory as long as command server uses
stdout as IPC channel.
The problem in commandserver was addressed by 766cfbe766dc, but it is tricky
to reuse ui.nontty option to disable echo back. Instead, this patch introduces
new option to enable echoing of prompt response.
Prompt echoing is changed to be off by default, which should avoid possible
breakage of output parsing in user scripts.
For now, this option is undocumented because it exists for internal use.
This just copies the same local sample hgrc, except it sets the
default path to the repo it was cloned from.
This is cut-and-paste from the local sample hgrc, but I think it's
acceptable, since the two pieces of code are right next to each other
and they're small. There is danger of them going out of synch, but it
would complicate the code too much to get rid of this C&P.
I also add ui as an import to hg.py, but with demandimport, this
should not be a noticeable performance hit.
Some examples of the typical configurations that one might want to do
in an .hg/hgrc file. This includes a default-push that happens to
point to the same location as my-fork.
I insist on the myfork terminology for a server-side clone. Bitbucket,
Github, and others have widely popularised this meaning of "fork".
This also includes a gentle nudge to use a repo-specific username,
which is something that people might not instinctively realise is an
option.
d735f8a82023 is nice for test output, but it also affects command-server
channel. Command-server client shouldn't receive echo-back message, which
makes it harder to parse the output.
The tests often set ui.interactive to control normally interactive prompts from
stdin. That gave an output where it was non-obvious what prompts got which
which response, and the output lacked the newline users would see after input.
Instead, if the input not is a tty, write the selection and a newline.
Retrieved from 55a66b5d9114.
I was about to move ' ' to label(msg + ' ', 'ui.prompt') so that subclass can
distinguish prompt output from data. But it was not that simple.
At the external editor invocation for committing, the value specified
as "editform" for "cmdutil.getcommiteditor" is in "HGEDITFORM".
This enables external editor to do own customization according to
commit types.
Command server is designed to use the channel protocol even if the server
process is accessible to tty, whereas vanilla hg should be able to read
password from tty in that case. So it isn't enough to swap sys.stdin:
# works only if the server process is detached from the console
sys.stdin = self.fin
getpass.getpass('')
sys.stdin = oldin
or test isatty:
# vanilla hg can't talk to tty if stdin is redirected
if self._isatty(self.fin):
return getpass.getpass('')
else:
...
Since ui.nontty flag is undocumented and command-server channels don't provide
isatty(), this change won't affect the other uses of ui._isatty().
issue3161 also suggests to provide some context of messages. I think it can
be implemented by using the generic templating function.
We need an easy way to capture both stderr and stdout during bundle2 processing
of a remote bundle. This changeset adds simple changes to the `ui` class to make
this possible.
I expect the interface to change in future releases as bundle2 will probably want to
distinguish stdout and stderr. The current change will, however, do for now.
transplant command set 'transplant_source' extra for the revision.
Allow an editor to access the extra using HGREVISION environment variable.
This may be useful when an editor is actually a script which modifies a commit
message. Transplant filters is an alternative way to do it.
rebase and graft commands set 'rebase_source' or 'source' extras for the revision.
Allow an editor to access the extras using HGREVISION environment variable.
This may be useful when an editor is actually a script which modifies a commit
message.
The name 'HGREVISION' has been selected as transplant already sets this variable
for its filters (--filter).
