Thread (86 messages) 86 messages, 8 authors, 2019-03-15

Re: regression in new built-in stash + fsmonitor (was Re: [PATCH v13 11/27] stash: convert apply to builtin)

From: Ævar Arnfjörð Bjarmason <hidden>
Date: 2019-03-14 15:40:37

On Thu, Mar 14 2019, Johannes Schindelin wrote:
Hi Ævar,

On Thu, 14 Mar 2019, Ævar Arnfjörð Bjarmason wrote:
quoted
On Tue, Feb 26 2019, Thomas Gummerer wrote:
quoted
From: Joel Teichroeb <redacted>

Add a builtin helper for performing stash commands. Converting
all at once proved hard to review, so starting with just apply
lets conversion get started without the other commands being
finished.

The helper is being implemented as a drop in replacement for
stash so that when it is complete it can simply be renamed and
the shell script deleted.

Delete the contents of the apply_stash shell function and replace
it with a call to stash--helper apply until pop is also
converted.
This

    GIT_TEST_FSMONITOR=$PWD/t7519/fsmonitor-all ./t3420-rebase-autostash.sh

Now fails, which bisects to 8a0fc8d19d ("stash: convert apply to
builtin", 2019-02-25).

Tested on both a CentOS 6 & modern Debian testing machine:

    + git rebase -i --autostash HEAD^
    Created autostash: 5cd734b
    HEAD is now at 0c4d2f1 third commit
    hint: Waiting for your editor to close the file...
    error: There was a problem with the editor '"$FAKE_EDITOR"'.
    Applied autostash.
    + exit_code=1
    + test 1 -eq 0
    + test_match_signal 13 1
    + test 1 = 141
    + test 1 = 269
    + return 1
    + test 1 -gt 129
    + test 1 -eq 127
    + test 1 -eq 126
    + return 0
    + rm -f abort-editor.sh
    + echo conflicting-content
    + test_cmp expected file0
    + diff -u expected file0
    --- expected    2019-03-14 13:19:08.212215263 +0000
    +++ file0       2019-03-14 13:19:08.196215250 +0000
    @@ -1 +1 @@
    -conflicting-content
    +uncommitted-content
    error: last command exited with $?=1
    not ok 36 - autostash is saved on editor failure with conflict

Are you able to reproduce this? And if so I suggest running the test
suite with some of the other GIT_TEST_* modes documented in
t/README. Maybe it'll turn up something else...
Yep, totally can reproduce it :-(
In the meantime I did a build with "next" (so stash-in-C) using the
standard test mode and these:

    (cd t && GIT_TEST_GETTEXT_POISON=true /usr/bin/prove $BKNG_GIT_HARNESS_OPTIONS t[0-9]*.sh)
    (cd t && GIT_TEST_FSMONITOR=$PWD/t7519/fsmonitor-all GIT_SKIP_TESTS="t3404.8 t3420.36" /usr/bin/prove $BKNG_GIT_HARNESS_OPTIONS t[0-9]*.sh)
    (cd t && GIT_TEST_SPLIT_INDEX=true /usr/bin/prove $BKNG_GIT_HARNESS_OPTIONS t[0-9]*.sh)
    (cd t && GIT_TEST_FULL_IN_PACK_ARRAY=true GIT_TEST_OE_SIZE=10 /usr/bin/prove $BKNG_GIT_HARNESS_OPTIONS t[0-9]*.sh)
    (cd t && GIT_TEST_COMMIT_GRAPH=true /usr/bin/prove $BKNG_GIT_HARNESS_OPTIONS t[0-9]*.sh)
    (cd t && GIT_TEST_MULTI_PACK_INDEX=true /usr/bin/prove $BKNG_GIT_HARNESS_OPTIONS t[0-9]*.sh)
    (cd t && GIT_TEST_STASH_USE_BUILTIN=false /usr/bin/prove $BKNG_GIT_HARNESS_OPTIONS t[0-9]*.sh)
    (cd t && GIT_TEST_CHECK_COLLISIONS=false /usr/bin/prove $BKNG_GIT_HARNESS_OPTIONS t[0-9]*.sh)

Only this specific test failed.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help