Re: [PATCH v4 3/3] worktree add: Add hint to use --orphan when bad ref

From: Jacob Abel <jacobabel@nullpo.dev>
Date: Dec 12, 2022, 14:59 UTC
Message-ID: <20221212145913.aftjeq6kn55zbkai@phi>
In-Reply-To: <221212.86pmcp57w4.gmgdl@evledraar.gmail.com>

On 22/12/12 09:35AM, Ævar Arnfjörð Bjarmason wrote:

Show 30 quoted lines

>
> On Mon, Dec 12 2022, Jacob Abel wrote:
>
> >  int git_default_advice_config(const char *var, const char *value);
> > diff --git a/builtin/worktree.c b/builtin/worktree.c
> > index 51b247b2a7..ea306e18de 100644
> > --- a/builtin/worktree.c
> > +++ b/builtin/worktree.c
> > @@ -744,6 +744,14 @@ static int add(int ac, const char **av, const char *prefix)
> >  		 * If `branch` does not reference a valid commit, a new
> >  		 * worktree (and/or branch) cannot be created based off of it.
> >  		 */
> > +		advise_if_enabled(ADVICE_WORKTREE_ADD_ORPHAN,
> > +			"If you meant to create a worktree containing a new orphan branch\n"
> > +			"(branch with no commits) for this repository, e.g. '%s',\n"
>
> I think this '%s' is just confusing, how is repeating the name of the
> branch at the user (which we're about to mention in the example command)
> helpful?
>
> Shouldn't we just omit it, or reword this to e.g.:
>
> 	If you'd like the '%s' branch to be a worktree containing a
> 	new....
>
>
> > +			"you can do so using the --orphan option:\n"
> > +			"\n"
> > +			"	git worktree add --orphan %s %s\n"
> > +			"\n",

Done.

Show 7 quoted lines

>
> Missing the usual:
>
> 	"Turn this message off by running\n"
> 	"\"git config advice.worktreeAddOrphan false\""
>
> blurb.

That blurb is added at runtime by `advise_if_enabled()`. I originally added it but it was giving me the line twice so I took it out.

>
> Also, should we really add twe newlines at the end? I see some other API
> users that don't add a \n at all.

Removed.

>
> > +# Helper function to test hints for using --orphan in an empty repo.
>
> FWIW I think we can do without the comment...

Removed.

Show 11 quoted lines

>
> > +test_wt_add_empty_repo_orphan_hint() {
> > +	local context="$1" &&
> > +	local opts="${@:2}" &&
>
> This appears to be some shell pseudo-syntax, and my shell hard-errors on
> this.
>
> But as we don't "shift" after the "$1" I don't see how what you
> *probably* meant could work, i.e. we always have arguments, so surely
> we'd always use "$@"?

Ah. The "${@:2}" is a bashism I think. I got it from [1] to try and grab all the remaining arguments. Changed to just shifting.

The &&ing together was a mistake on my part (not paying attention and mimicking the &&ing present in the test cases). I've removed that.

Show 16 quoted lines

>
>
> > +	test_expect_success "'worktree add' show orphan hint in empty repo w/ $context" '
> > +		test_when_finished "rm -rf empty_repo" &&
> > +		GIT_DIR="empty_repo" git init --bare &&
> > +		test_must_fail git -C empty_repo worktree add $opts 2> actual &&
> > +		grep "hint: If you meant to create a worktree containing a new orphan branch" actual
> > +	'
> > +}
> > +
> > +test_wt_add_empty_repo_orphan_hint 'DWIM' foobar/
> > +test_wt_add_empty_repo_orphan_hint '-b' -b foobar_branch foobar/
> > +test_wt_add_empty_repo_orphan_hint '-B' -B foobar_branch foobar/
>
> You're just testing how these options interact, so let's have the
> "foobar" part provided by the test function itself.

Done.

The following are what I have made for this set of changes (against v4).

diff --git a/builtin/worktree.c b/builtin/worktree.c
index 8bb1453e0f..38f7a27927 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -732,12 +732,11 @@ static int add(int ac, const char **av, const char *prefix)
        } else if (!lookup_commit_reference_by_name(branch)) {
                advise_if_enabled(ADVICE_WORKTREE_ADD_ORPHAN,
                        "If you meant to create a worktree containing a new orphan branch\n"
-                       "(branch with no commits) for this repository, e.g. '%s',\n"
-                       "you can do so using the --orphan option:\n"
+                       "(branch with no commits) for this repository, you can do so\n"
+                       "using the --orphan option:\n"
                        "\n"
-                       "       git worktree add --orphan %s %s\n"
-                       "\n",
-                        new_branch, new_branch, path);
+                       "       git worktree add --orphan %s %s\n",
+                        new_branch, path);
                die(_("invalid reference: %s"), branch);
        } else if (new_branch) {
                struct child_process cp = CHILD_PROCESS_INIT;
diff --git a/t/t2400-worktree-add.sh b/t/t2400-worktree-add.sh
index 0970989ee5..05539aa03c 100755
--- a/t/t2400-worktree-add.sh
+++ b/t/t2400-worktree-add.sh
@@ -375,21 +375,21 @@ test_expect_success '"add" worktree with orphan branch, lock, and reason' '
        test_cmp expect .git/worktrees/orphan-with-lock-reason/locked
 '

-# Helper function to test hints for using --orphan in an empty repo.
 test_wt_add_empty_repo_orphan_hint() {
-       local context="$1" &&
-       local opts="${@:2}" &&
+       local context="$1"
+       shift
+       local opts="$@"
        test_expect_success "'worktree add' show orphan hint in empty repo w/ $context" '
                test_when_finished "rm -rf empty_repo" &&
                GIT_DIR="empty_repo" git init --bare &&
-               test_must_fail git -C empty_repo worktree add $opts 2> actual &&
+               test_must_fail git -C empty_repo worktree add $opts foobar/ 2> actual &&
                grep "hint: If you meant to create a worktree containing a new orphan branch" actual
        '
 }

-test_wt_add_empty_repo_orphan_hint 'DWIM' foobar/
-test_wt_add_empty_repo_orphan_hint '-b' -b foobar_branch foobar/
-test_wt_add_empty_repo_orphan_hint '-B' -B foobar_branch foobar/
+test_wt_add_empty_repo_orphan_hint 'DWIM'
+test_wt_add_empty_repo_orphan_hint '-b' -b foobar_branch
+test_wt_add_empty_repo_orphan_hint '-B' -B foobar_branch

 test_expect_success 'local clone from linked checkout' '
        git clone --local here here-clone &&


Also, Is there an easier way to debug the `test_expect_success` statements? I
tried enabling tracing mode but it doesn't seem to trace into those statements.

1. https://stackoverflow.com/a/9057392/15064705