Hi dscho and Gábor On 24/06/2019 19:39, SZEDER Gábor wrote: > On Wed, Jun 12, 2019 at 09:14:40PM +0200, Johannes Schindelin wrote: >> Hi, >> >> On Tue, 11 Jun 2019, SZEDER Gábor wrote: >> >>> On Tue, Jun 11, 2019 at 01:36:16PM -0700, Junio C Hamano wrote: >>>> SZEDER Gábor <szeder.dev@xxxxxxxxx> writes: >>>> >>>>> -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. >>>>> EOF >>>> >>>> Yuck, >>> >>> Oh yeah... >>> >>>> ... 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... >>> >>>> 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) > > [...] > >> ++ test_cmp expect actual >> ++ GIT_ALLOC_LIMIT=0 >> ++ test-tool cmp expect actual >> diff --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). Those tests were added to check that `git stash` was being silenced (see 79a6226981 ("rebase -i: silence stash apply", 2017-05-18)). I can have a think about a better way to do that, but is it still a problem? I just tried to take a look at your CI output and https://dev.azure.com/gitgitgadget/git/_build/results?buildId=11406 seems to be all green - have I missed something or has Gábor fixed the issue? Best Wishes Phillip > > > [1] https://public-inbox.org/git/20190624181318.17388-3-szeder.dev@xxxxxxxxx/T/#u >
