(Tests pass on my mac as well)

(Sorry for the double send)

In D3716#58934, @indygreg wrote:

I agree with @yuja that we should move this to util.py or one of its siblings and rename it to uninterruptable or some such.

That being said, signal handlers are process global. And we do need to maintain persistent state so things don't get out of whack if we have overlapping calls, potentially from multiple threads (e.g. in the case of hgweb). So maybe ui.py - or even a global variable in that module - is the proper place for such state.

Also, I wonder if we shouldn't delay signal handling instead of ignoring it. e.g. our new signal handler would print that the signal was received and then raise KeyboardInterrupt at context manager exit time. Otherwise, the handling of SIGINT is timing dependent and doesn't consistently result in an aborted process.

In D3665#58616, @smf wrote:

johnstiles (John Stiles) <phabricator@mercurial-scm.org> writes:

johnstiles added a comment.

Hi there @indygreg and @yuja  -- are you happy with the diff as it currently stands? Do you think this needs any additional work?

Sorry for the late reply; was having email filtering issues (hopefully
fixed now).

Overall, I'm +0 on it because I think the "real" solution to this is to
templatize the graph glpyhs so any user could use whatever unicode they
desire. However, that's a tall order I wouldn't put on you so I'm fine
with putting this in and adding a note along the lines of, "the path to
get this in core is to get the graph log templated."

lgtm, but yuja had asked for sean and others to look, and I don't have push access :)

lgtm, and as long as there's no test differences seems fine. (I don't have ability to accept the patch, and this is from another Googler anyway, so this is just first-stage review).

In D3209#51512, @quark wrote:

Returning 1 is actually more consistent with other core commands like pull, push, commit. See https://www.mercurial-scm.org/pipermail/mercurial-devel/2012-January/037711.html. Scripts should be updated to use $? explicitly.

In D2729#46372, @martinvonz wrote:

Greg has some concerns about this patch and it sounds like you will make some changes. The patch was queued by Augie, but I'm dropping it for now, so we don't have a slightly controversial patch written by a Googler queued by two other Googlers.

Ah, there's a "Request Review" that I'd never noticed before, choosing that to hopefully get this out of "Requires Revision"

In D2889#46482, @yuja wrote:

Not reviewed yet, but this can't be applied cleanly. Can you rebase?

In D2729#45664, @indygreg wrote:

I'm sorry, but we cannot ship this as is.

The reason is mtime based build systems, like GNU make.

We can't have version control modifying files without bumping their mtime because this invalidates the target freshness checks of mtime-based build systems.

In D2678#45552, @durin42 wrote:

Ugh:

--- /home/augie/hg/tests/test-alias.t
+++ /home/augie/hg/tests/test-alias.t.err
@@ -357,15 +357,8 @@
 properly recursive

   $ hg dln
-  changeset:   -1:0000000000000000000000000000000000000000
-  phase:       public
-  parent:      -1:0000000000000000000000000000000000000000
-  parent:      -1:0000000000000000000000000000000000000000
-  manifest:    -1:0000000000000000000000000000000000000000
-  user:
-  date:        Thu Jan 01 00:00:00 1970 +0000
-  extra:       branch=default
-
+  abort: alias 'dln' resolves to unknown command 'lognull'
+  [255]

Neat, didn't know about the inline python stuff. That's much nicer.