gitweb, monoblue: port highlighting linked lines from paper This is adapted from 41c4bdd1d585, fbfe5748ef3e and f3393d458bf5.

gitweb, monoblue: fix vertical align of spans in .sourcelines Empty lines in file view could produce an inexplicable margin before the next line (most noticeable in browsers on webkit/blink engine). That was making empty lines seem taller than the rest. Instead of using default vertical align, let's set it to 'top'. This issue is actually present in paper, and only recently got into gitweb (2239626369f5) and monoblue (119202d4d7a4). There's a bit more to it in paper, so that will be dealt with in a future patch. Recipe to see live: preferably using a webkit/blink browser, such as chromium, browse a file with empty lines, e.g. https://selenic.com/hg/file/3.5/README#l8 Selecting a block of text that includes empty lines will reveal white "breaks" in the selection. Highlighted line (#l8) also shows such a break below itself.

merge: fix mergestate comment

rebase: avoid losing branch commits with --keepbranch (issue4835)

lock.release: do not unlink inherited locks This is part of a series that will allow locks to be inherited by subprocesses in limited circumstances. A subprocess unlinking a lock will lead to potential corruption from other concurrent processes.

lock: add a method to reacquire the lock after subprocesses exit This is part of a series that will allow locks to be inherited by subprocesses in limited circumstances.

lock: add a method to prepare the lock for inheritance This is part of a series that will allow locks to be inherited by subprocesses in limited circumstances.

lock: introduce state to keep track of inheritance This is part of a series that will allow locks to be inherited by subprocesses in limited circumstances. In upcoming patches we will refer to this state.

error: add an exception to indicate lock inheritance API contract violations

clone: check update rev for being True In 30be3aeb5344, there was an attempt to fallback to looking up the update revision assuming it was always a rev but the documentation states: True means update to default rev, anything else is treated as a revision Therefore, we should only fallback to looking up the update rev if it is not True. This bug was found in hg-git and I couldn't think of a test that does this in pure Mercurial since the source repository is checked for the revision as well (and therefore gracefully falls back).

clone: fix over-indented continuation line

resolve: consistently describe re-merge + unresolved

mercurial: add debugextensions command (issue4676) Add debugextensions command to help users debug their extension problems. If there are no extensions command prints nothing, otherwise it prints names of extension modules. If quiet or verbose option is not specified it prints(after extensions name) last version of mercurial in which given module was tested for non internal modules or not tested with user mercurial version. If verbose is specified it prints following information for every extension: extension name, import source, testedwith and buglink information. Extensions are printed sorted by extension name.

dispatch: stop warning about EPIPE in --debug mode It seems silly for "hg --debug manifest | less" to print a scary message after the user hits "q" in less. hg should just exit silently instead, since EPIPE on stdout is a perfectly reasonable result.

rebase: don't rebase obsolete commit whose successor is already rebased This patch avoids unnecessary conflicts to resolve during rebase for the users of changeset evolution. This patch modifies rebase to skip obsolete commits if they are being rebased on their successors. It introduces a new rebase state 'revprecursor' for these revisions that are being skipped and a new message to inform the user of what is happening. This feature is gated behind the config flag experimental.rebaseskipobsolete When an obsolete commit is skipped, the output is: not rebasing 14:9ad579b4a5de "I", already in destination as 17:fc37a630c901 "K"

check-code: forbid mutable value for default argument default value are common to all call. Using mutable value is a classical source of bug in Python. We forbid it. The regexp (Courtesy of Matt Mackall) is only catching such value on the first line of a definition, but that will be good enough for now.

httpconnection: remove a mutable default argument Mutable default arguments are know to the state of California to cause bugs.

transplant: remove a mutable default argument Mutable default arguments are know to the state of California to cause bugs.

mq: remove a mutable default argument Mutable default arguments are know to the state of California to cause bugs. The underlying function already handle "None" as an option value, so we do not need to do anything else.

largefiles: remove a mutable default argument Mutable default arguments are know to the state of California to cause bugs.

largefiles: remove a mutable default argument Mutable default arguments are know to the state of California to cause bugs.

largefiles: remove a mutable default argument Mutable default arguments are know to the state of California to cause bugs.

largefiles: remove a mutable default argument Mutable default arguments are know to the state of California to cause bugs.

largefiles: remove a mutable default argument Mutable default arguments are know to the state of California to cause bugs.