ui: check for progress singleton when clearing progress bar (issue5684) A combination of wrapping `ui` and progress bars interrupted by exceptions can lead to the progress bar not being cleared when the exception error is printed. This results in corrupted-looking output like this: ``` updating [===============================> ] 1/2u nresolved conflicts (see hg resolve, then hg rebase --continue) ``` This is because in `ui._progclear`, we only check the local reference to the progress bar, not whether or not there is an instance of the singleton. When a progress bar is interrupted by an exception, the exception printing in `scmutil.callcatch` uses the original instance of the `ui` object, not the wrapped copy that has `_progbar` set. When consider whether or not to clear the progress bar, check for the existence of the singleton, rather than just whether or not we have a local reference to it. Differential Revision: https://phab.mercurial-scm.org/D743

Added signature for changeset 920977f72c7b

Added tag 4.3.2 for changeset 920977f72c7b

merge with i18n

i18n-pt_BR: synchronized with 850d2ec2cf6a

hgwebdir: read 'web.template' untrusted The 'hgweb_mod.py' version of this read it untrusted. For consistency we align the two versions of this code.

ssh: fix flakey ssh errors on BSD systems This is a trivial backport of c037fd655b47 performed by augie@google.com, but the change is still really Durham's not mine, so I [augie] am leaving him as the author.

repair: preserve phase also when not using generaldelta (issue5678) It seems like we used to pick the oldest possible version of the changegroup to use for bundles created by the repair module (used e.g. by "hg strip" and for temporary bundles by "hg rebase"). I tried to preserve that behavior when I created the changegroup.safeversion() method in 3b2ac2115464 (changegroup: introduce safeversion(), 2016-01-19). However, we have recently chagned our minds and decided that these commands are only used locally and downgrades are unlikely. That decicion allowed us to start adding obsmarker and phase information to these bundles. However, as the bug report shows, it means we get different behavior e.g. when generaldelta is not enabled (because when it was enabled, it forced us to use bundle2). The commit that actually caused the reported bug was 8e3021fd1a44 (strip: include phases in bundle (BC), 2017-06-15). So, since we now depend on having more information in the bundles, let's make sure we instead pick the newest possible changegroup version. Differential Revision: https://phab.mercurial-scm.org/D715

tests: add test for issue5678 In addition to a test case for the direct problem described in the bug report, this also adds a test case showing how obsmarkers can also get lost when not using generaldelta. Differential Revision: https://phab.mercurial-scm.org/D714

mq: create non-lossy patches, also with custom global diff configuration Users with custom [diff] configuration most certainly didn't intend it to make mq lose changes. It could: * git is handled perfectly fine. * nobinary could make mq leave some files out from the patches. * noprefix could make mq itself (and probably also other tools) fail to apply patches without the usual a/b prefix. * ignorews, ignorewsamount, or ignoreblanklines could create patches with missing whitespace that could fail to apply correctly. Thus, when refreshing patches, use patch.difffeatureopts, optionally with git as before, but without the config options for whitespace and format changing that most likely will cause loss or problems. (patch.diffopts is just patch.difffeatureopts with all options enabled and can be replaced with that.)