git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com>
To: git@vger.kernel.org
Cc: Elijah Newren <newren@gmail.com>, Elijah Newren <newren@gmail.com>
Subject: [PATCH] t3424: new rebase testcase documenting a stat-dirty-like failure
Date: Mon, 17 Feb 2020 17:15:51 +0000	[thread overview]
Message-ID: <pull.712.git.git.1581959751454.gitgitgadget@gmail.com> (raw)

From: Elijah Newren <newren@gmail.com>

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

             reply	other threads:[~2020-02-17 17:15 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-17 17:15 Elijah Newren via GitGitGadget [this message]
2020-02-17 19:12 ` [PATCH] t3424: new rebase testcase documenting a stat-dirty-like failure Elijah Newren
2020-02-18 15:05   ` Phillip Wood
2020-02-18 15:59     ` Elijah Newren
2020-02-19 11:01       ` Phillip Wood
2020-02-19 16:00         ` Elijah Newren
2020-02-19 16:38           ` Junio C Hamano
2020-02-19 19:33           ` Phillip Wood
2020-02-18 14:03 ` Johannes Schindelin
2020-02-18 15:55   ` Elijah Newren
2020-02-18 20:55 ` [PATCH v2] " Elijah Newren via GitGitGadget
2020-02-18 21:33   ` Junio C Hamano
2020-02-18 22:01     ` Elijah Newren
2020-02-18 22:15   ` [PATCH v3] t3433: " Elijah Newren via GitGitGadget
2020-02-19 17:04     ` [PATCH v4 0/2] " Elijah Newren via GitGitGadget
2020-02-19 17:04       ` [PATCH v4 1/2] " Elijah Newren via GitGitGadget
2020-02-19 17:04       ` [PATCH v4 2/2] merge-recursive: fix the refresh logic in update_file_flags Elijah Newren via GitGitGadget
2020-02-19 18:40         ` Junio C Hamano
2020-02-19 19:32           ` Elijah Newren
2020-02-19 21:39             ` 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=pull.712.git.git.1581959751454.gitgitgadget@gmail.com \
    --to=gitgitgadget@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=newren@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).