Re: [PATCH v2 3/4] rebase: fix garbled progress display with '-x'
From: SZEDER Gábor <hidden>
Date: 2019-06-24 18:39:37
Possibly related (same subject, not in this thread)
- 2019-06-12 · Re: [PATCH v2 3/4] rebase: fix garbled progress display with '-x' · Junio C Hamano <hidden>
- 2019-06-11 · Re: [PATCH v2 3/4] rebase: fix garbled progress display with '-x' · SZEDER Gábor <hidden>
- 2019-06-11 · Re: [PATCH v2 3/4] rebase: fix garbled progress display with '-x' · Junio C Hamano <hidden>
- 2019-06-11 · [PATCH v2 3/4] rebase: fix garbled progress display with '-x' · SZEDER Gábor <hidden>
On Wed, Jun 12, 2019 at 09:14:40PM +0200, Johannes Schindelin wrote:
Hi, On Tue, 11 Jun 2019, SZEDER Gábor wrote:quoted
On Tue, Jun 11, 2019 at 01:36:16PM -0700, Junio C Hamano wrote:quoted
SZEDER Gábor [off-list ref] writes:quoted
-Rebasing (1/4)QRebasing (2/4)QRebasing (3/4)QRebasing (4/4)QSuccessfully rebased and updated refs/heads/missing-commit. +Rebasing (1/4)QRebasing (2/4)QRebasing (3/4)QRebasing (4/4)QQ QSuccessfully rebased and updated refs/heads/missing-commit. EOFYuck,Oh yeah...quoted
... but I do not see how else/better this test can be written myself, which makes it a double-yuck X-<Perhaps hiding those spaces behind a helper variable e.g. 'dump_term_clear_line=Q<80-spaces>Q' and embedding that in the here docs specifying the expected output in these three tests could make it ever so slightly less yuck...quoted
Are we forcing out test to operate under dumb terminal mode and with a known number of columns?'test-lib.sh' sets TERM=dumb relatively early on, and in these tests we don't use 'test_terminal' to run 'git rebase', so... yeah. And term_columns() defaults to 80. However, if the terminal were smart, then we would have to deal with ANSI escape suddenly popping up...And I fear that is *exactly* what makes https://dev.azure.com/gitgitgadget/git/_build/results?buildId=10539&view=ms.vss-test-web.build-test-results-tab fail... You cannot easily see it in that output (probably because of incorrectly encoded Escape sequences in the `.xml` output), so I'll paste what I see here, locally, when running `t3404-*.sh -i -V -x`: -- snip -- [...] ok 99 - rebase -i respects rebase.missingCommitsCheck = ignore expecting success: test_config rebase.missingCommitsCheck warn && rebase_setup_and_clean missing-commit && set_fake_editor && FAKE_LINES="1 2 3 4" \ git rebase -i --root 2>actual && test_i18ncmp expect actual && test D = $(git cat-file commit HEAD | sed -ne \$p)
[...]
quoted hunk ↗ jump to hunk
++ test_cmp expect actual ++ GIT_ALLOC_LIMIT=0 ++ test-tool cmp expect actualdiff --git a/expect b/actual index 05fcfcb..9555e34 100644 --- a/expect +++ b/actual@@ -6,4 +6,4 @@ To avoid this message, use "drop" to explicitly remove a commit. Use 'git config rebase.missingCommitsCheck' to change the level of warnings. The possible behaviours are: ignore, warn, error. -Rebasing (1/4)^MRebasing (2/4)^MRebasing (3/4)^MRebasing (4/4)^M ^MSuccessfully rebased and updated refs/heads/missing-commit. +Rebasing (1/4)^MRebasing (2/4)^MRebasing (3/4)^MRebasing (4/4)^MESC[KSuccessfully rebased and updated refs/heads/missing-commit.error: last command exited with $?=1 not ok 100 - rebase -i respects rebase.missingCommitsCheck = warn # # test_config rebase.missingCommitsCheck warn && # rebase_setup_and_clean missing-commit && # set_fake_editor && # FAKE_LINES="1 2 3 4" \ # git rebase -i --root 2>actual && # test_i18ncmp expect actual && # test D = $(git cat-file commit HEAD | sed -ne \$p) # -- snap -- (I copy-pasted this from the output of `less` so that the control sequences can be seen.) To be utterly honest, I really fail to see a reason why a test case that purports to verify that `git rebase -i` respects `rebase.missingCommitsCheck=warn` should fail when the progress is shown in an unexpected format. It strikes me as yet another poorly written test case that fails to catch the intended regressions, instead it catches a bug *in the test case itself* when legitimate changes are made to the progress code. Nothing in a test suite is worse than a test that fails (or succeeds) for the wrong reasons. To make things even worse, the code that generates that `expect` file is outside the test case. Here it is, in its full "glory": -- snip -- q_to_cr >expect <<EOF Warning: some commits may have been dropped accidentally. Dropped commits (newer to older): - $(git rev-list --pretty=oneline --abbrev-commit -1 master) To avoid this message, use "drop" to explicitly remove a commit. Use 'git config rebase.missingCommitsCheck' to change the level of warnings. The possible behaviours are: ignore, warn, error. Rebasing (1/4)QRebasing (2/4)QRebasing (3/4)QRebasing (4/4)QQ QSuccessfully rebased and updated refs/heads/missing-commit. EOF -- snap -- May I please *strongly* suggest to fix this first? It should - completely lose that last line, - be inserted into the test case itself so that e.g. disk full problems are caught and logged properly, and - the `test_i18ncmp expect actual` call in the test case should be replaced by something like: sed "\$d" <actual >actual-skip-progress && test_i18ncmp expect actual-skip-progress This should obviously be made as a separate, introductory patch (probably with a less scathing commit message than my comments above would suggest). And that would also remove the double-yuck.
Unfortunately, this addresses only one of the "Yuck"s; see v3 of this patch series [1]. The other yucks affect the following four tests in 't3420-rebase-autostash.sh': 16 - rebase --merge --autostash: check output 23 - rebase --merge: check output with conflicting stash 26 - rebase --interactive --autostash: check output 33 - rebase --interactive: check output with conflicting stash These tests come from commits b76aeae553 (rebase: add regression tests for console output, 2017-06-19) and 7d70e6b902 (rebase: add more regression tests for console output, 2017-06-19), and are specifically about checking the (whole) console output of 'git rebase', so I left the updates to them as they were. In any case, Cc-ing Phillip to discuss whether something could be done about them (now perhaps preferably (for me :) as a follow-up, and not another preparatory patches). [1] https://public-inbox.org/git/20190624181318.17388-3-szeder.dev@gmail.com/T/#u