view tests/test-revert-unknown.t @ 44261:04a3ae7aba14

chg: force-set LC_CTYPE on server start to actual value from the environment Python 3.7+ will "coerce" the LC_CTYPE variable in many instances, and this can cause issues with chg being able to start up. D7550 attempted to fix this, but a combination of a misreading of the way that python3.7 does the coercion and an untested state (LC_CTYPE being set to an invalid value) meant that this was still not quite working. This change will cause differences between chg and hg: hg will have the LC_CTYPE environment variable coerced, while chg will not. This is unlikely to cause any detectable behavior differences in what Mercurial itself outputs, but it does have two known effects: - When using hg, the coerced LC_CTYPE will be passed to subprocesses, even non-python ones. Using chg will remove the coercion, and this will not happen. This is arguably more correct behavior on chg's part. - On macOS, if you set your region to Brazil but your language to English, this isn't representable in locale strings, so macOS sets LC_CTYPE=UTF-8. If this value is passed along when ssh'ing to a non-macOS machine, some functions (such as locale.setlocale()) may raise an exception due to an unsupported locale setting. This is most easily encountered when doing an interactive commit/split/etc. when using ui.interface=curses. Differential Revision: https://phab.mercurial-scm.org/D8039
author Kyle Lippincott <spectral@google.com>
date Wed, 29 Jan 2020 13:39:50 -0800
parents 4c94b6d0fb1c
children 5c2a4f37eace
line wrap: on
line source

  $ hg init
  $ touch unknown

  $ touch a
  $ hg add a
  $ hg ci -m "1"

  $ touch b
  $ hg add b
  $ hg ci -m "2"

Should show unknown

  $ hg status
  ? unknown
  $ hg revert -r 0 --all
  removing b

Should show unknown and b removed

  $ hg status
  R b
  ? unknown

Should show a and unknown

  $ ls
  a
  unknown