From: Phillip Wood <phillip.wood123@gmail.com>
To: "SZEDER Gábor" <szeder.dev@gmail.com>,
"Johannes Schindelin" <Johannes.Schindelin@gmx.de>
Cc: Phillip Wood <phillip.wood@dunelm.org.uk>,
Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org
Subject: Re: [PATCH v2 3/4] rebase: fix garbled progress display with '-x'
Date: Tue, 25 Jun 2019 11:08:04 +0100 [thread overview]
Message-ID: <efc4a141-071a-6549-f25d-21cc6256832a@gmail.com> (raw)
In-Reply-To: <20190624183927.GA10853@szeder.dev>
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@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).
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@gmail.com/T/#u
>
next prev parent reply other threads:[~2019-06-25 10:08 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-30 14:25 [PATCH] rebase: fix garbled progress display with '-x' SZEDER Gábor
2019-04-30 22:25 ` Johannes Schindelin
2019-05-01 23:16 ` SZEDER Gábor
2019-05-03 8:41 ` Johannes Schindelin
2019-06-11 12:38 ` SZEDER Gábor
2019-06-11 13:03 ` [PATCH v2 0/4] rebase/progress: add and use term_clear_line() SZEDER Gábor
2019-06-11 13:03 ` [PATCH v2 1/4] t3404-rebase-interactive: use the 'q_to_cr' helper SZEDER Gábor
2019-06-11 13:03 ` [PATCH v2 2/4] pager: add a helper function to clear the last line in the terminal SZEDER Gábor
2019-06-11 13:03 ` [PATCH v2 3/4] rebase: fix garbled progress display with '-x' SZEDER Gábor
2019-06-11 20:36 ` Junio C Hamano
2019-06-11 21:11 ` SZEDER Gábor
2019-06-12 19:14 ` Johannes Schindelin
2019-06-12 19:41 ` SZEDER Gábor
2019-06-13 7:54 ` Johannes Schindelin
2019-06-14 18:42 ` Johannes Schindelin
2019-06-17 18:40 ` SZEDER Gábor
2019-06-17 19:13 ` SZEDER Gábor
2019-06-17 19:25 ` SZEDER Gábor
2019-06-24 18:39 ` SZEDER Gábor
2019-06-25 10:08 ` Phillip Wood [this message]
2019-06-25 11:31 ` SZEDER Gábor
2019-06-25 13:33 ` Phillip Wood
2019-06-25 18:00 ` Phillip Wood
2019-06-25 11:38 ` Johannes Schindelin
2019-06-25 13:35 ` Phillip Wood
2019-06-11 20:48 ` Junio C Hamano
2019-06-11 23:50 ` SZEDER Gábor
2019-06-12 16:21 ` Junio C Hamano
2019-06-11 13:03 ` [PATCH v2 4/4] progress: use term_clear_line() SZEDER Gábor
2019-06-12 20:00 ` Johannes Schindelin
2019-06-24 18:13 ` [PATCH v3 0/5] rebase/progress: add and " SZEDER Gábor
2019-06-24 18:13 ` [PATCH v3 1/5] t3404: modernize here doc style SZEDER Gábor
2019-06-25 9:06 ` Johannes Schindelin
2019-06-24 18:13 ` [PATCH v3 2/5] t3404: make the 'rebase.missingCommitsCheck=ignore' test more focused SZEDER Gábor
2019-06-25 9:07 ` Johannes Schindelin
2019-06-24 18:13 ` [PATCH v3 3/5] pager: add a helper function to clear the last line in the terminal SZEDER Gábor
2019-06-24 18:13 ` [PATCH v3 4/5] rebase: fix garbled progress display with '-x' SZEDER Gábor
2019-06-27 13:42 ` [PATCH v3.1 " SZEDER Gábor
2019-06-24 18:13 ` [PATCH v3 5/5] progress: use term_clear_line() SZEDER Gábor
2019-06-25 9:10 ` Johannes Schindelin
2019-06-25 19:44 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=efc4a141-071a-6549-f25d-21cc6256832a@gmail.com \
--to=phillip.wood123@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=phillip.wood@dunelm.org.uk \
--cc=szeder.dev@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).