Re: [PATCH] t3424: new rebase testcase documenting a stat-dirty-like failure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I forgot to add some cc's in GitGitGadget before submitting; adding now...

On Mon, Feb 17, 2020 at 9:15 AM Elijah Newren via GitGitGadget
<gitgitgadget@xxxxxxxxx> wrote:
>
> From: Elijah Newren <newren@xxxxxxxxx>
>
> A user discovered a case where they had a stack of 20 simple commits to
> rebase, and the rebase would succeed in picking the first commit and
> then error out with a pair of "Could not execute the todo command" and
> "Your local changes to the following files would be overwritten by
> merge" messages.
>
> Their steps actually made use of the -i flag, but I switched it over to
> -m to make it simpler to trigger the bug.  With that flag, it bisects
> back to commit 68aa495b590d (rebase: implement --merge via the
> interactive machinery, 2018-12-11), but that's misleading.  If you
> change the -m flag to --keep-empty, then the problem persists and will
> bisect back to 356ee4659bb5 (sequencer: try to commit without forking
> 'git commit', 2017-11-24)
>
> After playing with the testcase for a bit, I discovered that added
> --exec "sleep 1" to the command line makes the rebase succeed, making me
> suspect there is some kind of discard and reloading of caches that lead
> us to believe that something is stat dirty, but I didn't succeed in
> digging any further than that.
>
> Signed-off-by: Elijah Newren <newren@xxxxxxxxx>
> ---
>     t3424: new rebase testcase documenting a stat-dirty-like failure
>
>     A user discovered a case where they had a stack of 20 simple commits to
>     rebase, and the rebase would succeed in picking the first commit and
>     then error out with a pair of "Could not execute the todo command" and
>     "Your local changes to the following files would be overwritten by
>     merge" messages.
>
>     Their steps actually made use of the -i flag, but I switched it over to
>     -m to make it simpler to trigger the bug. With that flag, it bisects
>     back to commit 68aa495b590d (rebase: implement --merge via the
>     interactive machinery, 2018-12-11), but that's misleading. If you change
>     the -m flag to --keep-empty, then the problem persists and will bisect
>     back to 356ee4659bb5 (sequencer: try to commit without forking 'git
>     commit', 2017-11-24)
>
>     After playing with the testcase for a bit, I discovered that added
>     --exec "sleep 1" to the command line makes the rebase succeed, making me
>     suspect there is some kind of discard and reloading of caches that lead
>     us to believe that something is stat dirty, but I didn't succeed in
>     digging any further than that.
>
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-712%2Fnewren%2Fdocument-rebase-failure-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-712/newren/document-rebase-failure-v1
> Pull-Request: https://github.com/git/git/pull/712
>
>  t/t3424-rebase-across-mode-change.sh | 52 ++++++++++++++++++++++++++++
>  1 file changed, 52 insertions(+)
>  create mode 100755 t/t3424-rebase-across-mode-change.sh
>
> diff --git a/t/t3424-rebase-across-mode-change.sh b/t/t3424-rebase-across-mode-change.sh
> new file mode 100755
> index 00000000000..4d2eb1dd7c6
> --- /dev/null
> +++ b/t/t3424-rebase-across-mode-change.sh
> @@ -0,0 +1,52 @@
> +#!/bin/sh
> +
> +test_description='git rebase across mode change'
> +
> +. ./test-lib.sh
> +
> +test_expect_success 'setup' '
> +       rm -rf ../stupid &&
> +       git init ../stupid &&
> +       cd ../stupid &&
> +       mkdir DS &&
> +       >DS/whatever &&
> +       git add DS &&
> +       git commit -m base &&
> +
> +       git branch side1 &&
> +       git branch side2 &&
> +
> +       git checkout side1 &&
> +       git rm -rf DS &&
> +       ln -s unrelated DS &&
> +       git add DS &&
> +       git commit -m side1 &&
> +
> +       git checkout side2 &&
> +       >unrelated &&
> +       git add unrelated &&
> +       git commit -m commit1 &&
> +
> +       echo >>unrelated &&
> +       git commit -am commit2
> +'
> +
> +test_expect_success 'rebase changes with the apply backend' '
> +       test_when_finished "git rebase --abort || true" &&
> +       git checkout -b apply-backend side2 &&
> +       git rebase side1
> +'
> +
> +test_expect_failure 'rebase changes with the merge backend' '
> +       test_when_finished "git rebase --abort || true" &&
> +       git checkout -b merge-backend side2 &&
> +       git rebase -m side1
> +'
> +
> +test_expect_success 'rebase changes with the merge backend with a delay' '
> +       test_when_finished "git rebase --abort || true" &&
> +       git checkout -b merge-delay-backend side2 &&
> +       git rebase -m --exec "sleep 1" side1
> +'
> +
> +test_done
>
> base-commit: e68e29171cc2d6968902e0654b5687fbe1ccb903
> --
> gitgitgadget



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux