stdio: raise StdioError if something goes wrong in ui.flush The prior code used to ignore all errors, which was intended to deal with a decade-old problem with writing to broken pipes on Windows. However, that code inadvertantly went a lot further, making it impossible to detect *all* I/O errors on stdio ... but only sometimes. What actually happened was that if Mercurial wrote less than a stdio buffer's worth of output (the overwhelmingly common case for most commands), any error that occurred would get swallowed here. But if the buffering strategy changed, an unhandled IOError could be raised from any number of other locations. Because we now have a top-level StdioError handler, and ui._write and ui._write_err (and now flush!) will raise that exception, we have one rational place to detect and handle these errors.

stdio: raise StdioError if something goes wrong in ui._write_err The prior code used to ignore certain classes of error, which was not the right thing to do.

stdio: raise StdioError if something goes wrong in ui._write

stdio: catch StdioError in dispatch.run and clean up appropriately We attempt to report what went wrong, and more importantly exit the program with an error code. (The exception we catch is not yet raised anywhere in the code.)

stdio: add machinery to identify failed stdout/stderr writes Mercurial currently fails to notice failures to write to stdout or stderr. A correctly functioning command line tool should detect this and exit with an error code. To achieve this, we need a little extra plumbing, which we start adding here.

atexit: switch to home-grown implementation

atexit: test failing handlers

ui: add special-purpose atexit functionality In spite of its longstanding use, Python's built-in atexit code is not suitable for Mercurial's purposes, for several reasons: * Handlers run after application code has finished. * Because of this, the code that runs handlers swallows exceptions (since there's no possible stacktrace to associate errors with). If we're lucky, we'll get something spat out to stderr (if stderr still works), which of course isn't any use in a big deployment where it's important that exceptions get logged and aggregated. * Mercurial's current atexit handlers make unfortunate assumptions about process state (specifically stdio) that, coupled with the above problems, make it impossible to deal with certain categories of error (try "hg status > /dev/full" on a Linux box). * In Python 3, the atexit implementation is completely hidden, so we can't hijack the platform's atexit code to run handlers at a time of our choosing. As a result, here's a perfectly cromulent atexit-like implementation over which we have control. This lets us decide exactly when the handlers run (after each request has completed), and control what the process state is when that occurs (and afterwards).

context: follow all branches in blockdescendants() In the initial implementation of blockdescendants (and thus followlines(..., descend=True) revset), only the first branch encountered in descending direction was followed. Update the algorithm so that all children of a revision ('x' in code) are considered. Accordingly, we need to prevent a child revision to be yielded multiple times when it gets visited through different path, so we skip 'i' when this occurs. Finally, since we now consider all parents of a possible child touching a given line range, we take care of yielding the child if it has a diff in specified line range with at least one of its parent (same logic as blockancestors()).

pager: set some environment variables if they're not set Git did this already [1] [2]. We want this behavior too [3]. This provides a better default user experience (like, supporting colors) if users have things like "PAGER=less" set, which is not uncommon. The environment variables are provided by a method so extensions can override them on demand. [1]: https://github.com/git/git/blob/6a5ff7acb5965718cc7016c0ab6c601454fd7cde/pager.c#L87 [2]: https://github.com/git/git/blob/6a5ff7acb5965718cc7016c0ab6c601454fd7cde/Makefile#L1545 [3]: https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-March/094780.html

sshpeer: fix docstring typo

util: pass sysstrs to warnings.filterwarnings Un-breaks the Python 3 build.

vfs: deprecate all old classes in scmutil Now that all vfs class moved to the vfs module, we can deprecate the old one.

util: add a way to issue deprecation warning without a UI object Our current deprecation warning mechanism relies on ui object. They are case where we cannot have access to the UI object. On a general basis we avoid using the python mechanism for deprecation warning because up to Python 2.6 it is exposing warning to unsuspecting user who cannot do anything to deal with them. So we build a "safe" strategy to hide this warnings behind a flag in an environment variable. The test runner set this flag so that tests show these warning. This will help us marker API as deprecated for extensions to update their code.

gitweb: plug followlines UI in filerevision view Mostly copy CSS rules from style-paper.css into style-gitweb.css. The only modification is addition of !important on "background-color" rule for "pre.sourcelines > span.followlines-selected" selector as the background color is otherwise overriden by "pre.sourcelines.stripes > :nth-child(4n+4)" rule.

gitweb: handle "patch" query parameter in filelog view As for paper style, in f36dc643ffdc, we display "diff" data as an additional row in the table of revision entries for the gitweb template. Also, as these additional diff rows have a white background, they may be confused with log entry rows ("age", "author", "description", "links") of even parity (parity0 also have a white background). So we disable parity colors for log entry rows when diff is displayed and fix the color to the "dark" parity (i.e. parity1 #f6f6f0) so that it's always distinguishable from

gitweb: add information about "linerange" filtering in filelog view As for paper style, in 5e6d44511317, we display a "(following lines <fromline>:<toline> <a href='...'>back to filelog</a>)" message alongside the file name when "linerange" query parameter is present.

util: fix human-readable printing of negative byte counts Apply the same human-readable printing rules to negative byte counts as to positive ones. Fixes output of debugupgraderepo.

show: make template option actually show up in help Previously, the --template/-T option didn't show up in help because it's marked as experimental. It's not really experimental for show, and its quite important for show's funcationality, so let's make sure it always shows up.

show: implement underway view This is the beginning of a wip/smartlog view. It is basically a manually constructed (read: fast) revset function to collect "relevant" changesets combined with a custom template and a graph displayer. It obviously needs a lot of work. I'd like to get *something* usable in 4.2 so `hg show` has some value to end-users. Let the bikeshedding begin.

show: fix formatting of multiple commands Because we're formatting to RST, short lines wrap and there needs to be an extra line break between paragraphs to prevent that. In addition, the indentation in the old code was a bit off. Refactor the code to a function (so we don't leak variables outside the module) and modify it so it renders more correctly.

pycompat: import correct cookie module on Python 3 http.cookielib doesn't exist. http.cookiejar does and it contains the symbols we need. This fixes test failures on Python 3.

chg: respect environment variables for pager Previously chg runs the pager command without respecting its environment variables being told to use. This patch makes it so.

hgweb: add a link to followlines in descending direction We change the content of the followlines popup to display two links inviting to follow the history of selected lines in ascending (as before) and descending directions. The popup now renders as: follow history of lines <fromline>:<toline>: <a href=...>ascending</a> / <a href=...>descending</a>