worktree: teach "add" to ignore submodule.recurse config

"worktree add" internally calls "reset --hard", but if submodule.recurse is set, reset tries to recurse into initialized submodules, which makes start_command try to cd into non-existing submodule paths and die.

Fix that by making sure that the call to reset in "worktree add" does not recurse.

Some remarks:

1. This patch is based on maint

2. The 2 Travis CI macOS builds fail (they also fail on maint) with the message:

> +brew install caskroom/cask/perforce Error: caskroom/cask was moved. Tap homebrew/cask-cask instead. The command "ci/install-dependencies.sh" failed and exited with 1 during .

3. I'm on OS X 10.11.6 (Apple clang-800.0.42.1) and I get a warning

    compiling builtin/merge.c : 
    
    >     CC builtin/merge.o
    builtin/merge.c:831:33: warning: data argument not used by format string [-Wformat-extra-args]
                            no_scissors_editor_comment), comment_line_char);
                            ~~~~~~~~~~~~~~~~~~~~~~~~~~~  ^
    builtin/merge.c:809:4: note: format string is defined here
    N_("An empty message aborts the commit.\n");
       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ./gettext.h:86:20: note: expanded from macro 'N_'
    #define N_(msgid) (msgid)
                       ^~~~~
    1 warning generated.
    
    
     This makes me unable to build with DEVELOPER=1.

Philippe Blain (1):
worktree: teach "add" to ignore submodule.recurse config

 builtin/worktree.c      |  2 +-
 t/t2400-worktree-add.sh | 24 ++++++++++++++++++++++++
 2 files changed, 25 insertions(+), 1 deletion(-)

base-commit: 5fa0f5238b0cd46cfe7f6fa76c3f526ea98148d9
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-430%2Fphil-blain%2Fworktree-add-recurse-submodule-config-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-430/phil-blain/worktree-add-recurse-submodule-config-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/430

gitgitgadget

From: Philippe Blain <[email protected]>

"worktree add" internally calls "reset --hard", but if submodule.recurse is set, reset tries to recurse into initialized submodules, which makes start_command try to cd into non-existing submodule paths and die.

Fix that by making sure that the call to reset in "worktree add" does not recurse.

---
 builtin/worktree.c      |  2 +-
 t/t2400-worktree-add.sh | 24 ++++++++++++++++++++++++
 2 files changed, 25 insertions(+), 1 deletion(-)

index a5bb02b207..958bea97fe 100644
@@ -377,7 +377,7 @@ static int add_worktree(const char *path, const char *refname,
 	if (opts->checkout) {
 		cp.argv = NULL;
 		argv_array_clear(&cp.args);
-		argv_array_pushl(&cp.args, "reset", "--hard", NULL);
+		argv_array_pushl(&cp.args, "reset", "--hard", "--no-recurse-submodules", NULL);
 		if (opts->quiet)
 			argv_array_push(&cp.args, "--quiet");
 		cp.env = child_env.argv;

index e819ba741e..8a9831413c 100755
@@ -587,4 +587,28 @@ test_expect_success '"add" should not fail because of another bad worktree' '
 	)
 '
 
+test_expect_success '"add" with uninitialized submodule, with submodule.recurse unset' '
+	test_create_repo submodule &&
+	test_commit -C submodule first &&
+	test_create_repo project &&
+	git -C project submodule add ../submodule &&
+	git -C project add submodule &&
+	test_tick &&
+	git -C project commit -m add_sub &&
+	git clone project project-clone &&
+	git -C project-clone worktree add ../project-2
+'
+test_expect_success '"add" with uninitialized submodule, with submodule.recurse set' '
+	git -C project-clone -c submodule.recurse worktree add ../project-3
+'
+
+test_expect_success '"add" with initialized submodule, with submodule.recurse unset' '
+	git -C project-clone submodule update --init &&
+	git -C project-clone worktree add ../project-4
+'
+
+test_expect_success '"add" with initialized submodule, with submodule.recurse set' '
+	git -C project-clone -c submodule.recurse worktree add ../project-5
+'
+
 test_done

gitgitgadget

I am not sure if the compiler needs fixing in this case, but the following may work it around.

 builtin/merge.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

index e2ccbc44e2..0746f11df2 100644
@@ -826,9 +826,12 @@ static void prepare_to_commit(struct commit_list *remoteheads)
 			strbuf_commented_addf(&msg, "\n");
 		}
 		strbuf_commented_addf(&msg, _(merge_editor_comment));
-		strbuf_commented_addf(&msg, _(cleanup_mode == COMMIT_MSG_CLEANUP_SCISSORS ?
-			scissors_editor_comment :
-			no_scissors_editor_comment), comment_line_char);
+
+		if (cleanup_mode == COMMIT_MSG_CLEANUP_SCISSORS)
+			strbuf_commented_addf(&msg, _(scissors_editor_comment));
+		else
+			strbuf_commented_addf(&msg, _(no_scissors_editor_comment),
+					      comment_line_char);
 	}
 	if (signoff)
 		append_signoff(&msg, ignore_non_trailer(msg.buf, msg.len), 0);

Hi Junio,

That indeed makes the trick. Thanks!
Should I send a separate patch series with this patch ? How would that work ? "Signed-off by" me and "Based-on-patch-by" you ?

Philippe.

As I said, I am not sure if we even want a work-around or would want to just tell the compiler folks to fix their product, so I do not want to even have to decide if I should apply such a patch ;-)

But if this were a case where somebody suggested a small diff with "something like this perhaps?" and you wrapped it up as a proper patch (with log message, necessary bugfixes and clean-ups, and possibly tests if needed), just adding "Helped-by: somebody" followed by your s-o-b would be the norm. Anything more extensive you may want to give more credit to the original than helped-by, but in this case I do not think it even deserves that.