Here obj.__module__ and obj.__name__ are str. Either we can convert them to
bytes or use an r'' and convert back to bytes when concat is done. I preferred
the later one since we are encoding only once here.
The python hooks have access to the hook type information. There is not reason
for external hook to not be aware of it too.
For the record my use case is to make sure a hook script is configured for the
right type.
Same rational as for '_pythonhook', 'htype' is more accurate and less error
prone. We just fixed an error from the 'name'/'hname' confusion and this should
prevent them in the future.
We rename 'name' to 'htype' because it fits the variable content better.
Multiple python hooks already use 'htype' as a name for the argument. This makes
the difference with "hname" clearer and the code less error prone.
Almost all sys.stdin/out/err in hgext/ and mercurial/ are replaced by util's.
There are a few exceptions:
- lsprof.py and statprof.py are untouched since they are a kind of vendor
code and they never import mercurial modules right now.
- ui._readline() needs to replace sys.stdin and stdout to pass them to
raw_input(). We'll need another workaround here.
They were introduced at 07994b208874, where sys.stdout could be replaced by
sys.stderr. After that, we've changed the way of stdout redirection by
7d217b512ae2, so we no longer need to reference the original __stdout__ and
__stderr__ objects.
Let's move away from using __std*__ objects so we can simply wrap sys.std*
objects for Python 3 porting.
There was a similar issue to febfe464a80f. If an in-process hook writes
to stdout, the data may be buffered. In which case, stdout must be flushed
before restoring its file descriptor. Otherwise, remaining data would be sent
over the ssh wire and corrupts the protocol.
Note that this is a different redirection from the one I've just removed.
It was introduced by e0df29fe80bf to address command-server issues. After
that, I've made a complete fix by b096b3ac9391, so we don't need to replace
sys.stdio objects to protect the IPC channels.
This change means we no longer see data written to sys.stdout/err by an
in-process hook on command server. I think that's okay because the canonical
way is to use ui functions and in-process hooks should respect the Mercurial
API.
This will help Python 3 porting, where sys.stdout is TextIO but ui.fout is
BytesIO.
Before this patch, there was no way for a repository owner to ensure that
validation hooks would be run by people with write access. If someone had write
access but did not trust the user owning the repository, the config and its hook
would simply be ignored.
After this patch, hooks from untrusted configs are taken into account but never
actually run. Instead they are reported as failures right away. This will ensure
validation performed by a hook is not ignored.
As a side effect writer can be forced to trust a repository hgrc by adding a
'pretxnopen.trust=true' hook to the file.
This was discussed during the 3.8 sprint with Matt Mackall, Augie Fackler and
Kevin Bullock.
We want an easy way to fetch the hook config with and without honoring
"trusted" so that we can compare the values. So we extract the part
retrieving raw hook data from the config to be able to call it twice
in the next patch.
We are about to take untrusted hooks into account (to report them as failures)
so we need to rearrange the code a bit to allow config overwriting each other
in a later patch.
We had some real-world cases where syntax errors in Python hooks would crash
the whole process and leave it in an indeterminate state. Handle those better.
This matches 'hook failed' warnings.
We're also going to add hints to some of the hook load errors. Without this
change we'd have two pairs of parens for a single error message, which looks
really cluttered.
is None (issue4983)
Some hooks, such as post-init and post-clone, do not get a repo parameter in
their environment. If there is no repo, there is no repo.currenttransaction();
attempting to retrieve it anyway was causing crashes. Now currenttransaction is
only retrieved and written if the repo is not None.
Changeset e7b51de6e8eb alters the 'HG_PENDING' mechanism to be "always" there.
This change is made under the assumption than we previously did it only when
"writepending() actually wrote something". This assumption was wrong,
'writepending()' informs of pending changes the first time something is written
and for all following calls. We back this change out to restore the former
behavior, which was already correct.
Previously we would only include HG_PENDING in the hook args if the
transaction's writepending() actually wrote something. This is a bad criteria,
since it's possible that a previous call to writepending() wrote stuff and the
hooks want to still see that.
The solution is to always have hooks execute within the scope of the pending
changes by always putting HG_PENDING in the environment.
This patch centralizes passing HG_PENDING to external hook process
into '_exthook()'. To make in-memory changes visible to external hook
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
This patch tests some commands with some hooks, because transaction
activity of a same hook differs from each other ("---": "not tested").
======== ========= ========= ============
command preupdate precommit pretxncommit
======== ========= ========= ============
unshelve o --- ---
backout x --- ---
import --- o o
qrefresh --- x o
======== ========= ========= ============
Each hooks are examined separately to prevent in-memory changes from
being visible to external process accidentally by side effect of hooks
previously invoked.
The hook code treats python hooks raising an exception and returning True as
the exact same. This is OK for hooks themselves, but other code that wants to
invoke external code using the same underlying code is a bit more interested in
making a distinction.
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.
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 .`.
This seems like a textbook case for the new demandimport.deactivated
context manager: check if something must be done, do it, and cleanup
at the end regardless of exceptions.
The diff isn't as bad as it seems. It's just all the whitespace
changes due to needing an extra level of indentation. It looks cleaner
with `hg diff -w`.
There are a handful of SSH related test failures on Windows.
--- c:/Users/Matt/Projects/hg/tests/test-bundle2-exchange.t
+++ c:/Users/Matt/Projects/hg/tests/test-bundle2-exchange.t.err
@@ -305,16 +305,16 @@
remote: added 1 changesets with 1 changes to 1 files
remote: 1 new obsolescence markers
updating bookmark book_5fdd
+ pre-close-tip:02de42196ebe draft book_02de
+ postclose-tip:02de42196ebe draft book_02de
+ txnclose hook: HG_SOURCE=push-response HG_TXNNAME=push-response
+ ssh://user@dummy/other HG_URL=ssh://user@dummy/other
remote: pre-close-tip:5fddd98957c8 draft book_5fdd
remote: pushkey: lock state after "bookmarks"
remote: lock: free
remote: wlock: free
remote: postclose-tip:5fddd98957c8 draft book_5fdd
remote: txnclose hook: (env vars truncated)
- pre-close-tip:02de42196ebe draft book_02de
- postclose-tip:02de42196ebe draft book_02de
- txnclose hook: HG_SOURCE=push-response HG_TXNNAME=push-response
- ssh://user@dummy/other HG_URL=ssh://user@dummy/other
$ hg -R other log -G
o 6:5fddd98957c8 draft Nicolas Dumazet <...> book_5fdd C
|
--- c:/Users/Matt/Projects/hg/tests/test-ssh.t
+++ c:/Users/Matt/Projects/hg/tests/test-ssh.t.err
@@ -438,12 +438,12 @@
$ hg push
pushing to ssh://user@dummy/remote
searching for changes
+ local stdout
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files
- remote: KABOOM
- local stdout
+ remote: KABOOM\r (esc)
$ cd ..
What is happening is that no data is available in 'sshpeer.pipee' while the
command is executing. As the command completes, local output is printed, and
then sshpeer.cleanup() is called. When it calls 'self.pipeo.close()', the child
process is shutdown, flushing stderr.
As an experiment, I printed a line to stdout and another to stderr instead this
flush(). The stdout data was immediately available to the hg client, and none
of the stderr data was until the child exited. At that point, pipee has all of
the buffered data, and it is read out and printed before the pipe is closed in
sshpeer.cleanup(). This is probably a known issue, since ui.write_err()
mentions that stderr may be buffered, and also flushes stderr.
It would be nice if there was a more general fix (there is one more test that
fails), but I'm not sure what it is. I've seen (ancient) references [1] to
setvbuf() "crashing spectacularly" on some systems if any I/O has been done
already, so it seems worth avoiding.
https://sourceware.org/ml/gdb-patches/2013-08/msg00422.html
[1] https://groups.google.com/forum/#!msg/comp.lang.python/JT8LiYzYDEY/Qg9d1HwyjScJ
We need to gracefully handle some aborts for pushkey, especially
because it leads to a user-facing crash over the wireprotocols. So we
need a more specialized exception to catch.
There is no reason to expose unnecessary Python implementation details and
memory locations, also not in debug mode.
readablefunc was already creating a nice name - we move that functionality
up and reuse it.
We consider having a __call__ and being types.FunctionType sufficiently
similar and unify these two to just using the existing check for __call__.
This fixes an issue introduced in 818c8992811a where, when disabling
demandimport while running hooks, it's inadvertently re-enabled even when
it was never enabled in the first place.
This doesn't affect normal command line usage of Mercurial; it only matters
when Mercurial is run with demandimport intentionally disabled.
User 'timeless' in irc mentioned that having the blackbox be
translated would result in logs that:
- may be mixed language, if multiple users use the same repo
- are not google searchable (since searching for english gives more
results)
- might not be readable by an admin if the employee is using hg in
his native language
And therefore we should log everything in english.
Logs python and extension hooks to ui.log() for viewing in the blackbox.
Example log lines:
2013/02/09 08:35:19 durham> pythonhook-preupdate: hgext.eol.preupdate finished in 0.01 seconds
2013/02/09 08:35:19 durham> exthook-update: echo hooked finished in 0.02 seconds
