Re: [PATCH v2 3/4] rebase: fix garbled progress display with '-x'

["SZEDER Gábor" <szeder.dev@gmail.com>]

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@gmail.com> 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).


[1] https://public-inbox.org/git/20190624181318.17388-3-szeder.dev@gmail.com/T/#u