Mon, 08 Jul 2019 14:01:01 -0400 extdata: avoid crashing inside subprocess when we get a revset parse error
Augie Fackler <augie@google.com> [Mon, 08 Jul 2019 14:01:01 -0400] rev 42576
extdata: avoid crashing inside subprocess when we get a revset parse error Differential Revision: https://phab.mercurial-scm.org/D6616
Mon, 08 Jul 2019 13:57:44 -0400 extdata: demonstrate bad behavior when a subprocess emits garbage
Augie Fackler <augie@google.com> [Mon, 08 Jul 2019 13:57:44 -0400] rev 42575
extdata: demonstrate bad behavior when a subprocess emits garbage Differential Revision: https://phab.mercurial-scm.org/D6615
Sun, 07 Jul 2019 23:04:55 -0700 py3: don't run source transformer on hgext3rd (extensions)
Martin von Zweigbergk <martinvonz@google.com> [Sun, 07 Jul 2019 23:04:55 -0700] rev 42574
py3: don't run source transformer on hgext3rd (extensions) It's unclear why the source transformer runs on hgext3rd. It's been like that since it was introduced in 1c22400db72d (mercurial: implement a source transforming module loader on Python 3, 2016-07-04), and that commit didn't say anything about it (but it says that it doesn't have "support [...] for extensions"). I find that the current handling of hgext3rd just makes it harder to convert extensions to Python 3. It makes you convert a bunch of strings passed to getattr() and kwargs[] to r'' that could otherwise have been left alone. It's also really confusing that the source transformer runs when you import the extension as "extensions.foo=", but not as "extension.foo=/some/path". I suppose there is small number of (very simple) extensions that would have worked without this patch that would now be broken. It seems okay to me to break those. Differential Revision: https://phab.mercurial-scm.org/D6614
Mon, 08 Jul 2019 13:10:34 -0700 crecord: provide 'X' as a range-select mechanism
Kyle Lippincott <spectral@google.com> [Mon, 08 Jul 2019 13:10:34 -0700] rev 42573
crecord: provide 'X' as a range-select mechanism Differential Revision: https://phab.mercurial-scm.org/D6621
Mon, 08 Jul 2019 13:06:46 -0700 crecord: make KEY_ENTER usable in tests (by not updating UI)
Kyle Lippincott <spectral@google.com> [Mon, 08 Jul 2019 13:06:46 -0700] rev 42572
crecord: make KEY_ENTER usable in tests (by not updating UI) Differential Revision: https://phab.mercurial-scm.org/D6620
Mon, 08 Jul 2019 12:38:37 -0700 crecord: fix if -> elif when handling key presses
Kyle Lippincott <spectral@google.com> [Mon, 08 Jul 2019 12:38:37 -0700] rev 42571
crecord: fix if -> elif when handling key presses This shouldn't actually change any behavior, I only noticed it since I started using KEY_UP in tests, and it was complaining when it got down to the ^L handler that initscr hadn't been called yet. Differential Revision: https://phab.mercurial-scm.org/D6619
Mon, 08 Jul 2019 12:17:06 -0700 crecord: add "x" alias for space, remove test-only "TOGGLE" alias
Kyle Lippincott <spectral@google.com> [Mon, 08 Jul 2019 12:17:06 -0700] rev 42570
crecord: add "x" alias for space, remove test-only "TOGGLE" alias Differential Revision: https://phab.mercurial-scm.org/D6618
Mon, 08 Jul 2019 12:15:37 -0700 crecord: stop using test-only "X" as alternative for "c"
Kyle Lippincott <spectral@google.com> [Mon, 08 Jul 2019 12:15:37 -0700] rev 42569
crecord: stop using test-only "X" as alternative for "c" Differential Revision: https://phab.mercurial-scm.org/D6617
Sat, 06 Jul 2019 22:19:36 +0530 graft: moved abortgraft and readgraft to cmdutil
Taapas Agrawal <taapas2897@gmail.com> [Sat, 06 Jul 2019 22:19:36 +0530] rev 42568
graft: moved abortgraft and readgraft to cmdutil This patch moves `abortgraft` and `readgraft` to `cmdutil`. Various callers are updated accordingly. This is done because these serve as ulitlity functions for command `graft` and so that new functions regarding graft can be built from them. Differential Revision: https://phab.mercurial-scm.org/D6608
Thu, 20 Jun 2019 14:33:42 -0400 cleanup: use named constants for second arg to .seek()
Augie Fackler <augie@google.com> [Thu, 20 Jun 2019 14:33:42 -0400] rev 42567
cleanup: use named constants for second arg to .seek() Differential Revision: https://phab.mercurial-scm.org/D6556
Thu, 20 Jun 2019 14:45:52 -0700 patch: use a short, fixed-size message for last line of prompt (issue6158)
Kyle Lippincott <spectral@google.com> [Thu, 20 Jun 2019 14:45:52 -0700] rev 42566
patch: use a short, fixed-size message for last line of prompt (issue6158) See issue6158 and the previous commit for examples of what might go wrong if we have some combinations of readline version and terminal and need to wrap the line. Briefly: readline may not display the beginning of the last line of the prompt, or it may print over it with the end of the prompt, making it difficult for users to know what's going on. Differential Revision: https://phab.mercurial-scm.org/D6563
Thu, 20 Jun 2019 11:40:47 -0700 filemerge: make last line of prompts <40 english chars (issue6158)
Kyle Lippincott <spectral@google.com> [Thu, 20 Jun 2019 11:40:47 -0700] rev 42565
filemerge: make last line of prompts <40 english chars (issue6158) I've chosen <40 as the target so that other languages that may have a 2x blowup in character count can still have a chance to fit into an 80 column screen. Previously, we would show a prompt like: ``` keep (l)ocal [dest], take (o)ther [source], or leave (u)nresolved for some/potentially/really/long/path? ``` On at least some systems, if readline was in use then the last line of the prompt would be wrapped strangely if it couldn't fit entirely on one line. This strange wrapping may be just a carriage return without a line feed, overwriting the beginning of the line; example (100 columns wide, 65 character filename, and yes there's 10 spaces on the end, I assume this is to handle the user inputting longest word we provide as an option, "unresolved"): ``` ng/dir/name/that/does/not/work/well/with/readline/file.txt? ave (u)nresolved for some/lon ``` In some cases it may partially wrap onto the next line, but still be missing earlier parts in the line, such as below (60 columns wide, 65 character filename): ``` rev], or leave (u)nresolved for some/long/dir/name/that/do s/not/work/well/with/readline/file.txt? ``` With this fix, this looks like this on a 60 column screen: ``` tool vim_with_markers (for pattern some/long/dir/name/that/d oes/not/work/well/with/readline/file.txt) can't handle binar y tool meld can't handle binary tool vim_with_markers can't handle binary tool internal:merge3 can't handle binary tool merge can't handle binary no tool found to merge some/long/dir/name/that/does/not/work /well/with/readline/file.txt file 'some/long/dir/name/that/does/not/work/well/with/readli ne/file.txt' needs to be resolved. You can keep (l)ocal [working copy], take (o)ther [merge rev ], or leave (u)nresolved. What do you want to do? ``` Differential Revision: https://phab.mercurial-scm.org/D6562
(0) -30000 -10000 -3000 -1000 -300 -100 -12 +12 +100 +300 +1000 +3000 tip