threads / patch / 47657

patchworktree: teach "add" to check out existing branches

Subject: [PATCH] worktree: teach "add" to check out existing branches

## tl;dr

112 messages between Jan 21, 2018 and Apr 30, 2018. Diffs are folded; open one to read it.

replies: 111people: 5as markdown or json

Thomas Gummerer· Jan 21, 2018, 12:02 UTC · lore

Currently 'git worktree add <path>' creates a new branch named after the basename of the path by default. If a branch with that name already exists, the command refuses to do anything, unless the '--force' option is given.

However we can do a little better than that, and check the branch out if it is not checked out anywhere else. This will help users who just want to check an existing branch out into a new worktree, and save a few keystrokes.

As the current behaviour is to simply 'die()' when a brach with the name of the basename of the path already exists, there are no backwards compatibility worries here.

We will still 'die()' if the branch is checked out in another worktree, unless the --force flag is passed.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---

This is a follow-up to https://public-inbox.org/git/20171118181345.GC32324@hank/, where this was first suggested, but I didn't want to do it as part of that series. Now I finally got around to implementing it.

 Documentation/git-worktree.txt |  9 +++++++--
 builtin/worktree.c             | 22 +++++++++++++++-------
 t/t2025-worktree-add.sh        | 15 ++++++++++++---
 3 files changed, 34 insertions(+), 12 deletions(-)
Show changes to 3 files +34 −12

Documentation/git-worktree.txt, builtin/worktree.c, t/t2025-worktree-add.sh

diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index 41585f535d..98731b71a7 100644
--- a/Documentation/git-worktree.txt
+++ b/Documentation/git-worktree.txt
@@ -61,8 +61,13 @@ $ git worktree add --track -b <branch> <path> <remote>/<branch>
 ------------
 +
 If `<commit-ish>` is omitted and neither `-b` nor `-B` nor `--detach` used,
-then, as a convenience, a new branch based at HEAD is created automatically,
-as if `-b $(basename <path>)` was specified.
+then, as a convenience, a worktree with a branch named after
+`$(basename <path>)` (call it `<branch>`) is created.  If `<branch>`
+doesn't exist, a new branch based on HEAD is automatically created as
+if `-b <branch>` was given.  If `<branch>` exists in the repository,
+it will be checked out in the new worktree, if it's not checked out
+anywhere else, otherwise the command will refuse to create the
+worktree.
 
 list::
 
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 7cef5b120b..148a864bb9 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -411,13 +411,21 @@ static int add(int ac, const char **av, const char *prefix)
 	if (ac < 2 && !opts.new_branch && !opts.detach) {
 		int n;
 		const char *s = worktree_basename(path, &n);
-		opts.new_branch = xstrndup(s, n);
-		if (guess_remote) {
-			struct object_id oid;
-			const char *remote =
-				unique_tracking_name(opts.new_branch, &oid);
-			if (remote)
-				branch = remote;
+		const char *branchname = xstrndup(s, n);
+		struct strbuf ref = STRBUF_INIT;
+		if (!strbuf_check_branch_ref(&ref, branchname) &&
+		    ref_exists(ref.buf)) {
+			branch = branchname;
+			opts.checkout = 1;
+		} else {
+			opts.new_branch = branchname;
+			if (guess_remote) {
+				struct object_id oid;
+				const char *remote =
+					unique_tracking_name(opts.new_branch, &oid);
+				if (remote)
+					branch = remote;
+			}
 		}
 	}
 
diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
index 2b95944973..721b0e4c26 100755
--- a/t/t2025-worktree-add.sh
+++ b/t/t2025-worktree-add.sh
@@ -198,13 +198,22 @@ test_expect_success '"add" with <branch> omitted' '
 	test_cmp_rev HEAD bat
 '
 
-test_expect_success '"add" auto-vivify does not clobber existing branch' '
+test_expect_success '"add" auto-vivify checks out existing branch' '
 	test_commit c1 &&
 	test_commit c2 &&
 	git branch precious HEAD~1 &&
-	test_must_fail git worktree add precious &&
+	git worktree add precious &&
 	test_cmp_rev HEAD~1 precious &&
-	test_path_is_missing precious
+	(
+		cd precious &&
+		test_cmp_rev precious HEAD
+	)
+'
+
+test_expect_success '"add" auto-vivify fails with checked out branch' '
+	git checkout -b test-branch &&
+	test_must_fail git worktree add test-branch &&
+	test_path_is_missing test-branch
 '
 
 test_expect_success '"add" no auto-vivify with --detach and <branch> omitted' '

-- 
2.16.0.312.g896df04e46
Robert P. J. Day· Jan 21, 2018, 12:02 UTC · re: Thomas Gummerer · lore

Re: [PATCH] worktree: teach "add" to check out existing branches

On Sun, 21 Jan 2018, Thomas Gummerer wrote:
Show 11 quoted lines
> Currently 'git worktree add <path>' creates a new branch named after the
> basename of the path by default.  If a branch with that name already
> exists, the command refuses to do anything, unless the '--force' option
> is given.
>
> However we can do a little better than that, and check the branch out if
> it is not checked out anywhere else.  This will help users who just want
> to check an existing branch out into a new worktree, and save a few
> keystrokes.
>
> As the current behaviour is to simply 'die()' when a brach with the name
                                                       ^^^^^
Duy Nguyen· Jan 22, 2018, 11:18 UTC · re: Thomas Gummerer · lore

Re: [PATCH] worktree: teach "add" to check out existing branches

On Sun, Jan 21, 2018 at 7:02 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
Show 47 quoted lines
> Currently 'git worktree add <path>' creates a new branch named after the
> basename of the path by default.  If a branch with that name already
> exists, the command refuses to do anything, unless the '--force' option
> is given.
>
> However we can do a little better than that, and check the branch out if
> it is not checked out anywhere else.  This will help users who just want
> to check an existing branch out into a new worktree, and save a few
> keystrokes.
>
> As the current behaviour is to simply 'die()' when a brach with the name
> of the basename of the path already exists, there are no backwards
> compatibility worries here.
>
> We will still 'die()' if the branch is checked out in another worktree,
> unless the --force flag is passed.
>
> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
> ---
>
> This is a follow-up to
> https://public-inbox.org/git/20171118181345.GC32324@hank/, where this
> was first suggested, but I didn't want to do it as part of that
> series.  Now I finally got around to implementing it.
>
>  Documentation/git-worktree.txt |  9 +++++++--
>  builtin/worktree.c             | 22 +++++++++++++++-------
>  t/t2025-worktree-add.sh        | 15 ++++++++++++---
>  3 files changed, 34 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
> index 41585f535d..98731b71a7 100644
> --- a/Documentation/git-worktree.txt
> +++ b/Documentation/git-worktree.txt
> @@ -61,8 +61,13 @@ $ git worktree add --track -b <branch> <path> <remote>/<branch>
>  ------------
>  +
>  If `<commit-ish>` is omitted and neither `-b` nor `-B` nor `--detach` used,
> -then, as a convenience, a new branch based at HEAD is created automatically,
> -as if `-b $(basename <path>)` was specified.
> +then, as a convenience, a worktree with a branch named after
> +`$(basename <path>)` (call it `<branch>`) is created.  If `<branch>`
> +doesn't exist, a new branch based on HEAD is automatically created as
> +if `-b <branch>` was given.  If `<branch>` exists in the repository,
> +it will be checked out in the new worktree, if it's not checked out
> +anywhere else, otherwise the command will refuse to create the
> +worktree.

It starts getting a bit too magical to me. We probably should print something "switching to branch..." or "creating new branch ..." to let people know what decision was taken, unless --quiet is given. Yeah I know --quiet does not exist. You don't need to add it now either since nobody has asked for it.

More or less related to this, there was a question [1] whether we could do better than $(basename <path>) for determining branch name. Since you're doing start to check if a branch exists, people may start asking to check for branch "foo/bar" from the path abc/foo/bar instead of just branch "bar".

[1] https://github.com/git-for-windows/git/issues/1390
Show 20 quoted lines
>
>  list::
>
> diff --git a/builtin/worktree.c b/builtin/worktree.c
> index 7cef5b120b..148a864bb9 100644
> --- a/builtin/worktree.c
> +++ b/builtin/worktree.c
> @@ -411,13 +411,21 @@ static int add(int ac, const char **av, const char *prefix)
>         if (ac < 2 && !opts.new_branch && !opts.detach) {
>                 int n;
>                 const char *s = worktree_basename(path, &n);
> -               opts.new_branch = xstrndup(s, n);
> -               if (guess_remote) {
> -                       struct object_id oid;
> -                       const char *remote =
> -                               unique_tracking_name(opts.new_branch, &oid);
> -                       if (remote)
> -                               branch = remote;
> +               const char *branchname = xstrndup(s, n);
> +               struct strbuf ref = STRBUF_INIT;
Perhaps a blank line after this to separate var declarations and the rest.
> +               if (!strbuf_check_branch_ref(&ref, branchname) &&
> +                   ref_exists(ref.buf)) {
> +                       branch = branchname;
Hmm.. do we need UNLEAK(branch);? Maybe you should try valgrind, I'm not sure.
Show 46 quoted lines
> +                       opts.checkout = 1;
> +               } else {
> +                       opts.new_branch = branchname;
> +                       if (guess_remote) {
> +                               struct object_id oid;
> +                               const char *remote =
> +                                       unique_tracking_name(opts.new_branch, &oid);
> +                               if (remote)
> +                                       branch = remote;
> +                       }
>                 }
>         }
>
> diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
> index 2b95944973..721b0e4c26 100755
> --- a/t/t2025-worktree-add.sh
> +++ b/t/t2025-worktree-add.sh
> @@ -198,13 +198,22 @@ test_expect_success '"add" with <branch> omitted' '
>         test_cmp_rev HEAD bat
>  '
>
> -test_expect_success '"add" auto-vivify does not clobber existing branch' '
> +test_expect_success '"add" auto-vivify checks out existing branch' '
>         test_commit c1 &&
>         test_commit c2 &&
>         git branch precious HEAD~1 &&
> -       test_must_fail git worktree add precious &&
> +       git worktree add precious &&
>         test_cmp_rev HEAD~1 precious &&
> -       test_path_is_missing precious
> +       (
> +               cd precious &&
> +               test_cmp_rev precious HEAD
> +       )
> +'
> +
> +test_expect_success '"add" auto-vivify fails with checked out branch' '
> +       git checkout -b test-branch &&
> +       test_must_fail git worktree add test-branch &&
> +       test_path_is_missing test-branch
>  '
>
>  test_expect_success '"add" no auto-vivify with --detach and <branch> omitted' '
> --
> 2.16.0.312.g896df04e46
>
-- 
Duy
Thomas Gummerer· Jan 22, 2018, 20:17 UTC · re: Duy Nguyen · lore

Re: [PATCH] worktree: teach "add" to check out existing branches

On 01/22, Duy Nguyen wrote:
Show 19 quoted lines
> On Sun, Jan 21, 2018 at 7:02 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
> > [...]
> >  +
> >  If `<commit-ish>` is omitted and neither `-b` nor `-B` nor `--detach` used,
> > -then, as a convenience, a new branch based at HEAD is created automatically,
> > -as if `-b $(basename <path>)` was specified.
> > +then, as a convenience, a worktree with a branch named after
> > +`$(basename <path>)` (call it `<branch>`) is created.  If `<branch>`
> > +doesn't exist, a new branch based on HEAD is automatically created as
> > +if `-b <branch>` was given.  If `<branch>` exists in the repository,
> > +it will be checked out in the new worktree, if it's not checked out
> > +anywhere else, otherwise the command will refuse to create the
> > +worktree.
> 
> It starts getting a bit too magical to me. We probably should print
> something "switching to branch..." or "creating new branch ..."  to
> let people know what decision was taken, unless --quiet is given. Yeah
> I know --quiet does not exist. You don't need to add it now either
> since nobody has asked for it.
I think that's a good idea.  I'll add that, thanks.
Show 5 quoted lines
> More or less related to this, there was a question [1] whether we
> could do better than $(basename <path>) for determining branch name.
> Since you're doing start to check if a branch exists, people may start
> asking to check for branch "foo/bar" from the path abc/foo/bar instead
> of just branch "bar".

Thanks for pointing me at this. I feel like we might get ourselves some backwards compatibility worries when doing that. Lets say someone has a branch 'feature/a', using 'git worktree feature/a' would currently create a new branch 'a', and does not die.

I'd guess most users would want 'feature/a' checked out in that case, but we can't exactly be sure we won't break anyones workflow here. With your suggestion I guess that would be mitigated somehow as it shows which action is taken, but dunno.

Should we hide this behaviour behind a flag, and plan for it eventually becoming the default?

Show 24 quoted lines
> [1] https://github.com/git-for-windows/git/issues/1390
> 
> >
> >  list::
> >
> > diff --git a/builtin/worktree.c b/builtin/worktree.c
> > index 7cef5b120b..148a864bb9 100644
> > --- a/builtin/worktree.c
> > +++ b/builtin/worktree.c
> > @@ -411,13 +411,21 @@ static int add(int ac, const char **av, const char *prefix)
> >         if (ac < 2 && !opts.new_branch && !opts.detach) {
> >                 int n;
> >                 const char *s = worktree_basename(path, &n);
> > -               opts.new_branch = xstrndup(s, n);
> > -               if (guess_remote) {
> > -                       struct object_id oid;
> > -                       const char *remote =
> > -                               unique_tracking_name(opts.new_branch, &oid);
> > -                       if (remote)
> > -                               branch = remote;
> > +               const char *branchname = xstrndup(s, n);
> > +               struct strbuf ref = STRBUF_INIT;
> 
> Perhaps a blank line after this to separate var declarations and the rest.
Will add.
Show 5 quoted lines
> > +               if (!strbuf_check_branch_ref(&ref, branchname) &&
> > +                   ref_exists(ref.buf)) {
> > +                       branch = branchname;
> 
> Hmm.. do we need UNLEAK(branch);? Maybe you should try valgrind, I'm not sure.
Good question, I'll have a look, thanks.
Show 51 quoted lines
> > +                       opts.checkout = 1;
> > +               } else {
> > +                       opts.new_branch = branchname;
> > +                       if (guess_remote) {
> > +                               struct object_id oid;
> > +                               const char *remote =
> > +                                       unique_tracking_name(opts.new_branch, &oid);
> > +                               if (remote)
> > +                                       branch = remote;
> > +                       }
> >                 }
> >         }
> >
> > diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
> > index 2b95944973..721b0e4c26 100755
> > --- a/t/t2025-worktree-add.sh
> > +++ b/t/t2025-worktree-add.sh
> > @@ -198,13 +198,22 @@ test_expect_success '"add" with <branch> omitted' '
> >         test_cmp_rev HEAD bat
> >  '
> >
> > -test_expect_success '"add" auto-vivify does not clobber existing branch' '
> > +test_expect_success '"add" auto-vivify checks out existing branch' '
> >         test_commit c1 &&
> >         test_commit c2 &&
> >         git branch precious HEAD~1 &&
> > -       test_must_fail git worktree add precious &&
> > +       git worktree add precious &&
> >         test_cmp_rev HEAD~1 precious &&
> > -       test_path_is_missing precious
> > +       (
> > +               cd precious &&
> > +               test_cmp_rev precious HEAD
> > +       )
> > +'
> > +
> > +test_expect_success '"add" auto-vivify fails with checked out branch' '
> > +       git checkout -b test-branch &&
> > +       test_must_fail git worktree add test-branch &&
> > +       test_path_is_missing test-branch
> >  '
> >
> >  test_expect_success '"add" no auto-vivify with --detach and <branch> omitted' '
> > --
> > 2.16.0.312.g896df04e46
> >
> 
> 
> 
> -- 
> Duy
Thomas Gummerer· Feb 4, 2018, 22:13 UTC · re: Thomas Gummerer · lore

[PATCH v2 0/3] worktree: teach "add" to check out existing branches

The previous round was at <20180121120208.12760-1-t.gummerer@gmail.com>. Thanks Duy for the comments on the previous round.

In addition to the additional functionality, this series now includes improvements to the output of the "git worktree add" command. It doesn't include any new magic to guess the branchname, as was suggested, as that would be a bigger change in the behaviour of git worktree, and is not a particular itch I have right now, so I'd prefer to keep it separate.

Thomas Gummerer (3):
  worktree: improve message when creating a new worktree
  worktree: be clearer when "add" dwim-ery kicks in
  worktree: teach "add" to check out existing branches
 Documentation/git-worktree.txt |  9 +++++++--
 builtin/worktree.c             | 45 +++++++++++++++++++++++++++++++++---------
 t/t2025-worktree-add.sh        | 15 +++++++++++---
 3 files changed, 55 insertions(+), 14 deletions(-)
-- 
2.16.1.101.gde0f0111ea
Thomas Gummerer· Feb 4, 2018, 22:13 UTC · re: Thomas Gummerer · lore

[PATCH v2 1/3] worktree: improve message when creating a new worktree

Currently 'git worktree add' produces output like the following, when '--no-checkout' is not given:

    Preparing foo (identifier foo)
    HEAD is now at 26da330922 <title>

where the first line is written to stderr, and the second line coming from 'git reset --hard' is written to stdout, even though both lines are supposed to tell the user what has happened. In addition to someone not familiar with 'git worktree', this might seem as if the current HEAD was modified, not the HEAD in the new working tree.

If the '--no-checkout' flag is given, the output of 'git worktree add' is just:

    Preparing foo (identifier foo)
even though the HEAD is set to a commit, which is just not checked out.

Fix these inconsistencies by making the 'git reset --hard' call quiet, and printing the message ourselves instead.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---

We might want to do something similar for the 'git branch' command in the 'add()' function, which currently prints some output if a branch is set up to track a remote. I couldn't find a good way to convey that information in the output here, without making it too verbose, and it's probably not great to loose that output either.

If anyone has any suggestions for that, I'd be glad to hear them :)
 builtin/worktree.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)
Show changes to builtin/worktree.c +11 −2
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 7cef5b120b..d1549e441d 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -303,7 +303,7 @@ static int add_worktree(const char *path, const char *refname,
 	strbuf_addf(&sb, "%s/commondir", sb_repo.buf);
 	write_file(sb.buf, "../..");
 
-	fprintf_ln(stderr, _("Preparing %s (identifier %s)"), path, name);
+	fprintf(stderr, _("Preparing %s (identifier %s)"), path, name);
 
 	argv_array_pushf(&child_env, "%s=%s", GIT_DIR_ENVIRONMENT, sb_git.buf);
 	argv_array_pushf(&child_env, "%s=%s", GIT_WORK_TREE_ENVIRONMENT, path);
@@ -320,10 +320,19 @@ static int add_worktree(const char *path, const char *refname,
 	if (ret)
 		goto done;
 
+	fprintf(stderr, _(", setting HEAD to %s"),
+		find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
+
+	strbuf_reset(&sb);
+	pp_commit_easy(CMIT_FMT_ONELINE, commit, &sb);
+	if (sb.len > 0)
+		fprintf(stderr, " %s", sb.buf);
+	fputc('\n', stderr);
+
 	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", "--quiet", NULL);
 		cp.env = child_env.argv;
 		ret = run_command(&cp);
 		if (ret)

-- 
2.16.1.101.gde0f0111ea
Duy Nguyen· Feb 5, 2018, 02:12 UTC · re: Thomas Gummerer · lore

Re: [PATCH v2 1/3] worktree: improve message when creating a new worktree

On Sun, Feb 04, 2018 at 10:13:03PM +0000, Thomas Gummerer wrote:
Show 18 quoted lines
> diff --git a/builtin/worktree.c b/builtin/worktree.c
> index 7cef5b120b..d1549e441d 100644
> --- a/builtin/worktree.c
> +++ b/builtin/worktree.c
> @@ -303,7 +303,7 @@ static int add_worktree(const char *path, const char *refname,
>  	strbuf_addf(&sb, "%s/commondir", sb_repo.buf);
>  	write_file(sb.buf, "../..");
>  
> -	fprintf_ln(stderr, _("Preparing %s (identifier %s)"), path, name);
> +	fprintf(stderr, _("Preparing %s (identifier %s)"), path, name);
>  
>  	argv_array_pushf(&child_env, "%s=%s", GIT_DIR_ENVIRONMENT, sb_git.buf);
>  	argv_array_pushf(&child_env, "%s=%s", GIT_WORK_TREE_ENVIRONMENT, path);
> @@ -320,10 +320,19 @@ static int add_worktree(const char *path, const char *refname,
>  	if (ret)
>  		goto done;
>  
> +	fprintf(stderr, _(", setting HEAD to %s"),

As a former translator, I'm not thrilled to see a sentence broken into two pieces like this. I'm not a Japanese translator, but I think this sentence is translated differently when the translator sees the whole line "Preparing ..., setting ...".

Since the code between the first fprintf and this one should not take long to execute, perhaps we can just delete the first printf and print a whole [*] sentence here?

I think the purpose of "Preparing..." in the first place is to show something when git is busy checkout out the worktree. As long as we print it before git-reset, we should be good.

Show 6 quoted lines
> +		find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
> +
> +	strbuf_reset(&sb);
> +	pp_commit_easy(CMIT_FMT_ONELINE, commit, &sb);
> +	if (sb.len > 0)
> +		fprintf(stderr, " %s", sb.buf);

[*] Yes I know it's not "whole" because of this piece. But this one is more or less a separate sentence already so it's probably ok.

Is it a bit too long to print everything in one line though? CMIT_FMT_ONELINE could already fill 70 columns easily.

Show 13 quoted lines
> +	fputc('\n', stderr);
> +
>  	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", "--quiet", NULL);
>  		cp.env = child_env.argv;
>  		ret = run_command(&cp);
>  		if (ret)
> -- 
> 2.16.1.101.gde0f0111ea
>
Thomas Gummerer· Feb 5, 2018, 20:13 UTC · re: Duy Nguyen · lore

Re: [PATCH v2 1/3] worktree: improve message when creating a new worktree

On 02/05, Duy Nguyen wrote:
Show 24 quoted lines
> On Sun, Feb 04, 2018 at 10:13:03PM +0000, Thomas Gummerer wrote:
> > diff --git a/builtin/worktree.c b/builtin/worktree.c
> > index 7cef5b120b..d1549e441d 100644
> > --- a/builtin/worktree.c
> > +++ b/builtin/worktree.c
> > @@ -303,7 +303,7 @@ static int add_worktree(const char *path, const char *refname,
> >  	strbuf_addf(&sb, "%s/commondir", sb_repo.buf);
> >  	write_file(sb.buf, "../..");
> >  
> > -	fprintf_ln(stderr, _("Preparing %s (identifier %s)"), path, name);
> > +	fprintf(stderr, _("Preparing %s (identifier %s)"), path, name);
> >  
> >  	argv_array_pushf(&child_env, "%s=%s", GIT_DIR_ENVIRONMENT, sb_git.buf);
> >  	argv_array_pushf(&child_env, "%s=%s", GIT_WORK_TREE_ENVIRONMENT, path);
> > @@ -320,10 +320,19 @@ static int add_worktree(const char *path, const char *refname,
> >  	if (ret)
> >  		goto done;
> >  
> > +	fprintf(stderr, _(", setting HEAD to %s"),
> 
> As a former translator, I'm not thrilled to see a sentence broken into
> two pieces like this. I'm not a Japanese translator, but I think this
> sentence is translated differently when the translator sees the whole
> line "Preparing ..., setting ...".

Good point, I didn't think about the sentence structure other languages could require here.

Show 20 quoted lines
> Since the code between the first fprintf and this one should not take
> long to execute, perhaps we can just delete the first printf and print
> a whole [*] sentence here?
> 
> I think the purpose of "Preparing..." in the first place is to show
> something when git is busy checkout out the worktree. As long as we
> print it before git-reset, we should be good.
> 
> > +		find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
> > +
> > +	strbuf_reset(&sb);
> > +	pp_commit_easy(CMIT_FMT_ONELINE, commit, &sb);
> > +	if (sb.len > 0)
> > +		fprintf(stderr, " %s", sb.buf);
> 
> [*] Yes I know it's not "whole" because of this piece. But this one is
> more or less a separate sentence already so it's probably ok.
> 
> Is it a bit too long to print everything in one line though?
> CMIT_FMT_ONELINE could already fill 70 columns easily.

Yeah, it does get a bit long. Maybe just splitting the sentences here would be the best solution, then we also won't have to worry about the split not being good for translation. I'll do that.

Show 13 quoted lines
> > +	fputc('\n', stderr);
> > +
> >  	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", "--quiet", NULL);
> >  		cp.env = child_env.argv;
> >  		ret = run_command(&cp);
> >  		if (ret)
> > -- 
> > 2.16.1.101.gde0f0111ea
> >
Junio C Hamano· Feb 5, 2018, 20:15 UTC · re: Duy Nguyen · lore

Re: [PATCH v2 1/3] worktree: improve message when creating a new worktree

Duy Nguyen <pclouds@gmail.com> writes:
Show 28 quoted lines
> On Sun, Feb 04, 2018 at 10:13:03PM +0000, Thomas Gummerer wrote:
>> diff --git a/builtin/worktree.c b/builtin/worktree.c
>> index 7cef5b120b..d1549e441d 100644
>> --- a/builtin/worktree.c
>> +++ b/builtin/worktree.c
>> @@ -303,7 +303,7 @@ static int add_worktree(const char *path, const char *refname,
>>  	strbuf_addf(&sb, "%s/commondir", sb_repo.buf);
>>  	write_file(sb.buf, "../..");
>>  
>> -	fprintf_ln(stderr, _("Preparing %s (identifier %s)"), path, name);
>> +	fprintf(stderr, _("Preparing %s (identifier %s)"), path, name);
>>  
>>  	argv_array_pushf(&child_env, "%s=%s", GIT_DIR_ENVIRONMENT, sb_git.buf);
>>  	argv_array_pushf(&child_env, "%s=%s", GIT_WORK_TREE_ENVIRONMENT, path);
>> @@ -320,10 +320,19 @@ static int add_worktree(const char *path, const char *refname,
>>  	if (ret)
>>  		goto done;
>>  
>> +	fprintf(stderr, _(", setting HEAD to %s"),
>
> As a former translator, I'm not thrilled to see a sentence broken into
> two pieces like this. I'm not a Japanese translator, but I think this
> sentence is translated differently when the translator sees the whole
> line "Preparing ..., setting ...".
>
> Since the code between the first fprintf and this one should not take
> long to execute, perhaps we can just delete the first printf and print
> a whole [*] sentence here?

Yeah, also it is a bit troubling that "Preparing" is an incomplete line, and when update-ref/symblic-ref call fails, will stay to be incomplete.

Show 13 quoted lines
> I think the purpose of "Preparing..." in the first place is to show
> something when git is busy checkout out the worktree. As long as we
> print it before git-reset, we should be good.
>
>> +		find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
>> +
>> +	strbuf_reset(&sb);
>> +	pp_commit_easy(CMIT_FMT_ONELINE, commit, &sb);
>> +	if (sb.len > 0)
>> +		fprintf(stderr, " %s", sb.buf);
>
> [*] Yes I know it's not "whole" because of this piece. But this one is
> more or less a separate sentence already so it's probably ok.

Doing all the additional fprintf/fputc at the same place (instead of across update-ref/symbolic-ref) would make it easier to follow and also allow it to make "whole" even with that piece. Prepare the abbreviated commit->object.oid.hash and FMT_ONELINE in the same strbuf and say that the HEAD is there. I think it also makes sense to split it into two sentences, so from that point of view, just dropping the change in the "Preparing" hunk and then saying "HEAD is now at '9876fdea title of the commit'" after update/symbolic-ref may also be a good change. That automatically removes the "what hapepns to the rest of the incomplete line when run_command() fails?" issue.

Show 16 quoted lines
> Is it a bit too long to print everything in one line though?
> CMIT_FMT_ONELINE could already fill 70 columns easily.
>
>> +	fputc('\n', stderr);
>> +
>>  	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", "--quiet", NULL);
>>  		cp.env = child_env.argv;
>>  		ret = run_command(&cp);
>>  		if (ret)
>> -- 
>> 2.16.1.101.gde0f0111ea
>>
Eric Sunshine· Feb 7, 2018, 08:51 UTC · re: Duy Nguyen · lore

Re: [PATCH v2 1/3] worktree: improve message when creating a new worktree

On Sun, Feb 4, 2018 at 9:12 PM, Duy Nguyen <pclouds@gmail.com> wrote:
Show 8 quoted lines
> As a former translator, I'm not thrilled to see a sentence broken into
> two pieces like this. I'm not a Japanese translator, but I think this
> sentence is translated differently when the translator sees the whole
> line "Preparing ..., setting ...".
>
> I think the purpose of "Preparing..." in the first place is to show
> something when git is busy checkout out the worktree. As long as we
> print it before git-reset, we should be good.

The original message was "Enter <worktree>" which had the potential to confuse someone into thinking the working directory had changed[1], so it was changed to "Preparing...". The reason for keeping that message (rather than dropping it outright) was to provide context to messages printed after it, especially messages such as "HEAD is now at..." which might otherwise confuse the reader into thinking that HEAD in the current worktree changed rather than HEAD in the new worktree[2,3].

[1]: https://public-inbox.org/git/55A8F4B1.9060304@drmicha.warpmail.net/ [2]: https://public-inbox.org/git/CAPig+cRSHwmmF9cCUbRrDCCW4kvg9PeOUxP5VQpSGfxzMxHWOQ@mail.gmail.com/ [3]: https://public-inbox.org/git/CAPig+cSLs4-uKicVMBSKnEro_FYD722Hs1_U6qzTriM8Ciok2Q@mail.gmail.com/

Thomas Gummerer· Feb 9, 2018, 11:27 UTC · re: Eric Sunshine · lore

Re: [PATCH v2 1/3] worktree: improve message when creating a new worktree

On 02/07, Eric Sunshine wrote:
Show 18 quoted lines
> On Sun, Feb 4, 2018 at 9:12 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> > As a former translator, I'm not thrilled to see a sentence broken into
> > two pieces like this. I'm not a Japanese translator, but I think this
> > sentence is translated differently when the translator sees the whole
> > line "Preparing ..., setting ...".
> >
> > I think the purpose of "Preparing..." in the first place is to show
> > something when git is busy checkout out the worktree. As long as we
> > print it before git-reset, we should be good.
> 
> The original message was "Enter <worktree>" which had the potential to
> confuse someone into thinking the working directory had changed[1], so
> it was changed to "Preparing...". The reason for keeping that message
> (rather than dropping it outright) was to provide context to messages
> printed after it, especially messages such as "HEAD is now at..."
> which might otherwise confuse the reader into thinking that HEAD in
> the current worktree changed rather than HEAD in the new
> worktree[2,3].

Thanks for the background! In that light, since we're already customizing the "HEAD is now at..." message, is it worth dropping the message now, maybe using something like "Worktree HEAD is now at ...", or something similar?

This would loose the information about the identifier of the worktree, but from a coarse look at the man page it doesn't seem like we advertise that widely (The only thing related to it I could find is

    If the last path components in the working tree's path is unique among
    working trees, it can be used to identify worktrees. For example if
    you only have two working trees, at "/abc/def/ghi" and "/abc/def/ggg",
    then "ghi" or "def/ghi" is enough to point to the former working tree.

for which we don't need to print the identifier anywhere. We don't seem to mention the case where the last part is unique, and we add a number to make the identifier unique.

So given that maybe it would even be better to hide the part about the identifier, as it seems more like an implementation detail than relevant to the end user?

> [1]: https://public-inbox.org/git/55A8F4B1.9060304@drmicha.warpmail.net/
> [2]: https://public-inbox.org/git/CAPig+cRSHwmmF9cCUbRrDCCW4kvg9PeOUxP5VQpSGfxzMxHWOQ@mail.gmail.com/
> [3]: https://public-inbox.org/git/CAPig+cSLs4-uKicVMBSKnEro_FYD722Hs1_U6qzTriM8Ciok2Q@mail.gmail.com/
Duy Nguyen· Feb 9, 2018, 12:08 UTC · re: Thomas Gummerer · lore

Re: [PATCH v2 1/3] worktree: improve message when creating a new worktree

On Fri, Feb 9, 2018 at 6:27 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
Show 9 quoted lines
> This would loose the information about the identifier of the worktree,
> but from a coarse look at the man page it doesn't seem like we
> advertise that widely
>
> ...
>
> So given that maybe it would even be better to hide the part about the
> identifier, as it seems more like an implementation detail than
> relevant to the end user?

Exactly. I'd rather hide it. I haven't found any good reason that a user needs to know these IDs unless they poke into $GIT_DIR/worktrees, but they should not need to.

-- 
Duy
Duy Nguyen· Feb 10, 2018, 11:20 UTC · re: Duy Nguyen · lore

Re: [PATCH v2 1/3] worktree: improve message when creating a new worktree

On Fri, Feb 9, 2018 at 7:08 PM, Duy Nguyen <pclouds@gmail.com> wrote:
Show 14 quoted lines
> On Fri, Feb 9, 2018 at 6:27 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
>> This would loose the information about the identifier of the worktree,
>> but from a coarse look at the man page it doesn't seem like we
>> advertise that widely
>>
>> ...
>>
>> So given that maybe it would even be better to hide the part about the
>> identifier, as it seems more like an implementation detail than
>> relevant to the end user?
>
> Exactly. I'd rather hide it. I haven't found any good reason that a
> user needs to know these IDs unless they poke into $GIT_DIR/worktrees,
> but they should not need to.

Just FYI. I mentioned elsewhere [1] the possibility of a new extended ref syntax to refer to e.g. HEAD from a different worktree. Such syntax may make use of this id (which also means we might need to give the user control over these ids and not just always auto generate them).

But that's for the future. If/When that thing comes, we can worry about displaying id here then. For now I still think it's ok to hide it.

[1] https://public-inbox.org/git/20180210095952.GA9035@ash/T/#u
-- 
Duy
Thomas Gummerer· Feb 4, 2018, 22:13 UTC · re: Thomas Gummerer · lore

[PATCH v2 2/3] worktree: be clearer when "add" dwim-ery kicks in

Currently there is no indication in the "git worktree add" output that a new branch was created. This would be especially useful information in the case where the dwim of "git worktree add <path>" kicks in, as the user didn't explicitly ask for a new branch, but we create one from them.

Print some additional output showing that a branch was created and the branch name to help the user.

This will also be useful in the next commit, which introduces a new kind of dwim-ery of checking out the branch if it exists instead of refusing to create a new worktree in that case, and where it's nice to tell the user which kind of dwim-ery kicked in.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 builtin/worktree.c | 3 +++
 1 file changed, 3 insertions(+)
Show changes to builtin/worktree.c +3 −0
diff --git a/builtin/worktree.c b/builtin/worktree.c
index d1549e441d..74a853c2a3 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -320,6 +320,9 @@ static int add_worktree(const char *path, const char *refname,
 	if (ret)
 		goto done;
 
+	if (opts->new_branch)
+		fprintf(stderr, _(", creating new branch '%s'"), opts->new_branch);
+
 	fprintf(stderr, _(", setting HEAD to %s"),
 		find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
 

-- 
2.16.1.101.gde0f0111ea
Thomas Gummerer· Feb 4, 2018, 22:13 UTC · re: Thomas Gummerer · lore

[PATCH v2 3/3] worktree: teach "add" to check out existing branches

Currently 'git worktree add <path>' creates a new branch named after the basename of the path by default. If a branch with that name already exists, the command refuses to do anything, unless the '--force' option is given.

However we can do a little better than that, and check the branch out if it is not checked out anywhere else. This will help users who just want to check an existing branch out into a new worktree, and save a few keystrokes.

As the current behaviour is to simply 'die()' when a branch with the name of the basename of the path already exists, there are no backwards compatibility worries here.

We will still 'die()' if the branch is checked out in another worktree, unless the --force flag is passed.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 Documentation/git-worktree.txt |  9 +++++++--
 builtin/worktree.c             | 31 +++++++++++++++++++++++--------
 t/t2025-worktree-add.sh        | 15 ++++++++++++---
 3 files changed, 42 insertions(+), 13 deletions(-)
Show changes to 3 files +42 −13

Documentation/git-worktree.txt, builtin/worktree.c, t/t2025-worktree-add.sh

diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index 41585f535d..98731b71a7 100644
--- a/Documentation/git-worktree.txt
+++ b/Documentation/git-worktree.txt
@@ -61,8 +61,13 @@ $ git worktree add --track -b <branch> <path> <remote>/<branch>
 ------------
 +
 If `<commit-ish>` is omitted and neither `-b` nor `-B` nor `--detach` used,
-then, as a convenience, a new branch based at HEAD is created automatically,
-as if `-b $(basename <path>)` was specified.
+then, as a convenience, a worktree with a branch named after
+`$(basename <path>)` (call it `<branch>`) is created.  If `<branch>`
+doesn't exist, a new branch based on HEAD is automatically created as
+if `-b <branch>` was given.  If `<branch>` exists in the repository,
+it will be checked out in the new worktree, if it's not checked out
+anywhere else, otherwise the command will refuse to create the
+worktree.
 
 list::
 
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 74a853c2a3..ea420bb90b 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -29,6 +29,7 @@ struct add_opts {
 	int keep_locked;
 	const char *new_branch;
 	int force_new_branch;
+	int checkout_existing_branch;
 };
 
 static int show_only;
@@ -320,7 +321,10 @@ static int add_worktree(const char *path, const char *refname,
 	if (ret)
 		goto done;
 
-	if (opts->new_branch)
+	if (opts->checkout_existing_branch)
+		fprintf(stderr, _(", checking out existing branch '%s'"),
+			refname);
+	else if (opts->new_branch)
 		fprintf(stderr, _(", creating new branch '%s'"), opts->new_branch);
 
 	fprintf(stderr, _(", setting HEAD to %s"),
@@ -423,14 +427,25 @@ static int add(int ac, const char **av, const char *prefix)
 	if (ac < 2 && !opts.new_branch && !opts.detach) {
 		int n;
 		const char *s = worktree_basename(path, &n);
-		opts.new_branch = xstrndup(s, n);
-		if (guess_remote) {
-			struct object_id oid;
-			const char *remote =
-				unique_tracking_name(opts.new_branch, &oid);
-			if (remote)
-				branch = remote;
+		const char *branchname = xstrndup(s, n);
+		struct strbuf ref = STRBUF_INIT;
+
+		if (!strbuf_check_branch_ref(&ref, branchname) &&
+		    ref_exists(ref.buf)) {
+			branch = branchname;
+			opts.checkout_existing_branch = 1;
+			UNLEAK(branch);
+		} else {
+			opts.new_branch = branchname;
+			if (guess_remote) {
+				struct object_id oid;
+				const char *remote =
+					unique_tracking_name(opts.new_branch, &oid);
+				if (remote)
+					branch = remote;
+			}
 		}
+		strbuf_release(&ref);
 	}
 
 	if (ac == 2 && !opts.new_branch && !opts.detach) {
diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
index 2b95944973..721b0e4c26 100755
--- a/t/t2025-worktree-add.sh
+++ b/t/t2025-worktree-add.sh
@@ -198,13 +198,22 @@ test_expect_success '"add" with <branch> omitted' '
 	test_cmp_rev HEAD bat
 '
 
-test_expect_success '"add" auto-vivify does not clobber existing branch' '
+test_expect_success '"add" auto-vivify checks out existing branch' '
 	test_commit c1 &&
 	test_commit c2 &&
 	git branch precious HEAD~1 &&
-	test_must_fail git worktree add precious &&
+	git worktree add precious &&
 	test_cmp_rev HEAD~1 precious &&
-	test_path_is_missing precious
+	(
+		cd precious &&
+		test_cmp_rev precious HEAD
+	)
+'
+
+test_expect_success '"add" auto-vivify fails with checked out branch' '
+	git checkout -b test-branch &&
+	test_must_fail git worktree add test-branch &&
+	test_path_is_missing test-branch
 '
 
 test_expect_success '"add" no auto-vivify with --detach and <branch> omitted' '

-- 
2.16.1.101.gde0f0111ea
Duy Nguyen· Feb 5, 2018, 02:18 UTC · re: Thomas Gummerer · lore

Re: [PATCH v2 3/3] worktree: teach "add" to check out existing branches

On Sun, Feb 04, 2018 at 10:13:05PM +0000, Thomas Gummerer wrote:
Show 6 quoted lines
> -	if (opts->new_branch)
> +	if (opts->checkout_existing_branch)
> +		fprintf(stderr, _(", checking out existing branch '%s'"),
> +			refname);
> +	else if (opts->new_branch)
>  		fprintf(stderr, _(", creating new branch '%s'"), opts->new_branch);
I wonder if "creating branch" and "checkout out branch" are enough.
Show 25 quoted lines
> @@ -423,14 +427,25 @@ static int add(int ac, const char **av, const char *prefix)
>  	if (ac < 2 && !opts.new_branch && !opts.detach) {
>  		int n;
>  		const char *s = worktree_basename(path, &n);
> -		opts.new_branch = xstrndup(s, n);
> -		if (guess_remote) {
> -			struct object_id oid;
> -			const char *remote =
> -				unique_tracking_name(opts.new_branch, &oid);
> -			if (remote)
> -				branch = remote;
> +		const char *branchname = xstrndup(s, n);
> +		struct strbuf ref = STRBUF_INIT;
> +
> +		if (!strbuf_check_branch_ref(&ref, branchname) &&
> +		    ref_exists(ref.buf)) {
> +			branch = branchname;
> +			opts.checkout_existing_branch = 1;
> +			UNLEAK(branch);
> +		} else {
> +			opts.new_branch = branchname;
> +			if (guess_remote) {
> +				struct object_id oid;
> +				const char *remote =
> +					unique_tracking_name(opts.new_branch, &oid);

Deep indentation may be a sign that it's time to move all this code to a separate function, maybe dwim_branch() or something.

Show 8 quoted lines
> +				if (remote)
> +					branch = remote;
> +			}
>  		}
> +		strbuf_release(&ref);
>  	}
>  
>  	if (ac == 2 && !opts.new_branch && !opts.detach) {
Junio C Hamano· Feb 5, 2018, 20:20 UTC · re: Duy Nguyen · lore

Re: [PATCH v2 3/3] worktree: teach "add" to check out existing branches

Duy Nguyen <pclouds@gmail.com> writes:
Show 9 quoted lines
> On Sun, Feb 04, 2018 at 10:13:05PM +0000, Thomas Gummerer wrote:
>> -	if (opts->new_branch)
>> +	if (opts->checkout_existing_branch)
>> +		fprintf(stderr, _(", checking out existing branch '%s'"),
>> +			refname);
>> +	else if (opts->new_branch)
>>  		fprintf(stderr, _(", creating new branch '%s'"), opts->new_branch);
>
> I wonder if "creating branch" and "checkout out branch" are enough.

Yeah, I think new/existing are redundant. If these were shown at the same time, then the extra adjectives would help differenciating them visually, but they are never shown at the same time, so...

Thomas Gummerer· Feb 5, 2018, 20:23 UTC · re: Duy Nguyen · lore

Re: [PATCH v2 3/3] worktree: teach "add" to check out existing branches

On 02/05, Duy Nguyen wrote:
Show 9 quoted lines
> On Sun, Feb 04, 2018 at 10:13:05PM +0000, Thomas Gummerer wrote:
> > -	if (opts->new_branch)
> > +	if (opts->checkout_existing_branch)
> > +		fprintf(stderr, _(", checking out existing branch '%s'"),
> > +			refname);
> > +	else if (opts->new_branch)
> >  		fprintf(stderr, _(", creating new branch '%s'"), opts->new_branch);
> 
> I wonder if "creating branch" and "checkout out branch" are enough.

I thought printing the branch name might be a good idea just to show more clearly what the dwim did. Especially if we ever introduce new heuristics, for example to cater for the case you mentioned in an earlier email [1], I thought it might be helpful to also print the branch name. Especially because it makes it clear that the dwim the reporter of the github issue hoped for didn't kick in at this point.

That said, I don't really think the branchname is of much use for my usage of 'git worktree add', so I may be overestimating the need for it. I'm happy to remove it if that's preferred.

[1]: <CACsJy8D9LS7e=cVE3Fq2qOnxK5++nFg2vjuhkNtRO-Bx0X1j6w@mail.gmail.com>
Show 28 quoted lines
> > @@ -423,14 +427,25 @@ static int add(int ac, const char **av, const char *prefix)
> >  	if (ac < 2 && !opts.new_branch && !opts.detach) {
> >  		int n;
> >  		const char *s = worktree_basename(path, &n);
> > -		opts.new_branch = xstrndup(s, n);
> > -		if (guess_remote) {
> > -			struct object_id oid;
> > -			const char *remote =
> > -				unique_tracking_name(opts.new_branch, &oid);
> > -			if (remote)
> > -				branch = remote;
> > +		const char *branchname = xstrndup(s, n);
> > +		struct strbuf ref = STRBUF_INIT;
> > +
> > +		if (!strbuf_check_branch_ref(&ref, branchname) &&
> > +		    ref_exists(ref.buf)) {
> > +			branch = branchname;
> > +			opts.checkout_existing_branch = 1;
> > +			UNLEAK(branch);
> > +		} else {
> > +			opts.new_branch = branchname;
> > +			if (guess_remote) {
> > +				struct object_id oid;
> > +				const char *remote =
> > +					unique_tracking_name(opts.new_branch, &oid);
> 
> Deep indentation may be a sign that it's time to move all this code to
> a separate function, maybe dwim_branch() or something.
Makes sense, I'll factor it out.  Thanks!
Show 8 quoted lines
> > +				if (remote)
> > +					branch = remote;
> > +			}
> >  		}
> > +		strbuf_release(&ref);
> >  	}
> >  
> >  	if (ac == 2 && !opts.new_branch && !opts.detach) {
Duy Nguyen· Feb 6, 2018, 11:53 UTC · re: Thomas Gummerer · lore

Re: [PATCH v2 3/3] worktree: teach "add" to check out existing branches

On Tue, Feb 6, 2018 at 3:23 AM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
Show 13 quoted lines
> On 02/05, Duy Nguyen wrote:
>> On Sun, Feb 04, 2018 at 10:13:05PM +0000, Thomas Gummerer wrote:
>> > -   if (opts->new_branch)
>> > +   if (opts->checkout_existing_branch)
>> > +           fprintf(stderr, _(", checking out existing branch '%s'"),
>> > +                   refname);
>> > +   else if (opts->new_branch)
>> >             fprintf(stderr, _(", creating new branch '%s'"), opts->new_branch);
>>
>> I wonder if "creating branch" and "checkout out branch" are enough.
>
> I thought printing the branch name might be a good idea just to show
> more clearly what the dwim did.

No no printing branch name is definitely a good idea, especially when I think of one thing and type another. I shortened my example phrases too much. It should have been "creating branch %s" and "checkout out branch %s"

-- 
Duy
Thomas Gummerer· Feb 9, 2018, 11:04 UTC · re: Duy Nguyen · lore

Re: [PATCH v2 3/3] worktree: teach "add" to check out existing branches

On 02/06, Duy Nguyen wrote:
Show 19 quoted lines
> On Tue, Feb 6, 2018 at 3:23 AM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
> > On 02/05, Duy Nguyen wrote:
> >> On Sun, Feb 04, 2018 at 10:13:05PM +0000, Thomas Gummerer wrote:
> >> > -   if (opts->new_branch)
> >> > +   if (opts->checkout_existing_branch)
> >> > +           fprintf(stderr, _(", checking out existing branch '%s'"),
> >> > +                   refname);
> >> > +   else if (opts->new_branch)
> >> >             fprintf(stderr, _(", creating new branch '%s'"), opts->new_branch);
> >>
> >> I wonder if "creating branch" and "checkout out branch" are enough.
> >
> > I thought printing the branch name might be a good idea just to show
> > more clearly what the dwim did.
> 
> No no printing branch name is definitely a good idea, especially when
> I think of one thing and type another. I shortened my example phrases
> too much. It should have been "creating branch %s" and "checkout out
> branch %s"
Ah sorry I misunderstood.  Yeah I think that makes sense then :)
> -- 
> Duy
Thomas Gummerer· Mar 17, 2018, 22:08 UTC · re: Thomas Gummerer · lore

[PATCH v3 0/4] worktree: teach "add" to check out existing branches

Previous rounds are at <20180121120208.12760-1-t.gummerer@gmail.com> and <20180204221305.28300-1-t.gummerer@gmail.com>. Thanks Duy, Eric and Junio for the comments on the previous round.

Junio: I know it is the rc period right now, but the topic is also
already queued in 'pu', so I wasn't sure if you prefer me submitting
this now, or after 2.17 is released.  I'm happy to resend this once
2.17 is out if that makes it easier for you.

This round improves the end user facing messages, and factors out a dwim_branch function as suggested by Duy.

Interdiff below:
Show changes to builtin/worktree.c +32 −26
diff --git a/builtin/worktree.c b/builtin/worktree.c
index ea420bb90b..b5d273751f 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -304,8 +304,6 @@ static int add_worktree(const char *path, const char *refname,
 	strbuf_addf(&sb, "%s/commondir", sb_repo.buf);
 	write_file(sb.buf, "../..");
 
-	fprintf(stderr, _("Preparing %s (identifier %s)"), path, name);
-
 	argv_array_pushf(&child_env, "%s=%s", GIT_DIR_ENVIRONMENT, sb_git.buf);
 	argv_array_pushf(&child_env, "%s=%s", GIT_WORK_TREE_ENVIRONMENT, path);
 	cp.git_cmd = 1;
@@ -322,12 +320,12 @@ static int add_worktree(const char *path, const char *refname,
 		goto done;
 
 	if (opts->checkout_existing_branch)
-		fprintf(stderr, _(", checking out existing branch '%s'"),
+		fprintf(stderr, _("checking out branch '%s'"),
 			refname);
 	else if (opts->new_branch)
-		fprintf(stderr, _(", creating new branch '%s'"), opts->new_branch);
+		fprintf(stderr, _("creating branch '%s'"), opts->new_branch);
 
-	fprintf(stderr, _(", setting HEAD to %s"),
+	fprintf(stderr, _("worktree HEAD is now at %s"),
 		find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
 
 	strbuf_reset(&sb);
@@ -373,6 +371,32 @@ static int add_worktree(const char *path, const char *refname,
 	return ret;
 }
 
+static const char *dwim_branch(const char *path, struct add_opts *opts)
+{
+	int n;
+	const char *s = worktree_basename(path, &n);
+	const char *branchname = xstrndup(s, n);
+	struct strbuf ref = STRBUF_INIT;
+
+	if (!strbuf_check_branch_ref(&ref, branchname) &&
+	    ref_exists(ref.buf)) {
+		*branch = branchname;
+		opts->checkout_existing_branch = 1;
+		strbuf_release(&ref);
+		UNLEAK(branchname);
+		return branchname;
+	}
+
+	opts->new_branch = branchname;
+	if (guess_remote) {
+		struct object_id oid;
+		const char *remote =
+			unique_tracking_name(opts->new_branch, &oid);
+		return remote;
+	}
+	return NULL;
+}
+
 static int add(int ac, const char **av, const char *prefix)
 {
 	struct add_opts opts;
@@ -425,27 +449,9 @@ static int add(int ac, const char **av, const char *prefix)
 	}
 
 	if (ac < 2 && !opts.new_branch && !opts.detach) {
-		int n;
-		const char *s = worktree_basename(path, &n);
-		const char *branchname = xstrndup(s, n);
-		struct strbuf ref = STRBUF_INIT;
-
-		if (!strbuf_check_branch_ref(&ref, branchname) &&
-		    ref_exists(ref.buf)) {
-			branch = branchname;
-			opts.checkout_existing_branch = 1;
-			UNLEAK(branch);
-		} else {
-			opts.new_branch = branchname;
-			if (guess_remote) {
-				struct object_id oid;
-				const char *remote =
-					unique_tracking_name(opts.new_branch, &oid);
-				if (remote)
-					branch = remote;
-			}
-		}
-		strbuf_release(&ref);
+		const char *dwim_branchname = dwim_branch(path, &opts);
+		if (dwim_branchname)
+			branch = dwim_branchname;
 	}
 
 	if (ac == 2 && !opts.new_branch && !opts.detach) {

Thomas Gummerer (4):
  worktree: improve message when creating a new worktree
  worktree: be clearer when "add" dwim-ery kicks in
  worktree: factor out dwim_branch function
  worktree: teach "add" to check out existing branches

 Documentation/git-worktree.txt |  9 +++--
 builtin/worktree.c             | 60 +++++++++++++++++++++++++---------
 t/t2025-worktree-add.sh        | 15 +++++++--
 3 files changed, 64 insertions(+), 20 deletions(-)

-- 
2.17.0.rc0.231.g781580f06
Thomas Gummerer· Mar 17, 2018, 22:08 UTC · re: Thomas Gummerer · lore

[PATCH v3 1/4] worktree: improve message when creating a new worktree

Currently 'git worktree add' produces output like the following, when '--no-checkout' is not given:

    Preparing foo (identifier foo)
    HEAD is now at 26da330922 <title>

where the first line is written to stderr, and the second line coming from 'git reset --hard' is written to stdout, even though both lines are supposed to tell the user what has happened. In addition to someone not familiar with 'git worktree', this might seem as if the current HEAD was modified, not the HEAD in the new working tree.

If the '--no-checkout' flag is given, the output of 'git worktree add' is just:

    Preparing foo (identifier foo)
even though the HEAD is set to a commit, which is just not checked out.

The identifier is also not particularly relevant for the user at the moment, as it's only used internally to distinguish between different worktrees that have the same $(basename <path>).

Fix these inconsistencies, and no longer show the identifier by making the 'git reset --hard' call quiet, and printing the message directly from the builtin command instead.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 builtin/worktree.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)
Show changes to builtin/worktree.c +10 −3
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 7cef5b120b..e5d04f0b4b 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -303,8 +303,6 @@ static int add_worktree(const char *path, const char *refname,
 	strbuf_addf(&sb, "%s/commondir", sb_repo.buf);
 	write_file(sb.buf, "../..");
 
-	fprintf_ln(stderr, _("Preparing %s (identifier %s)"), path, name);
-
 	argv_array_pushf(&child_env, "%s=%s", GIT_DIR_ENVIRONMENT, sb_git.buf);
 	argv_array_pushf(&child_env, "%s=%s", GIT_WORK_TREE_ENVIRONMENT, path);
 	cp.git_cmd = 1;
@@ -320,10 +318,19 @@ static int add_worktree(const char *path, const char *refname,
 	if (ret)
 		goto done;
 
+	fprintf(stderr, _("worktree HEAD is now at %s"),
+		find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
+
+	strbuf_reset(&sb);
+	pp_commit_easy(CMIT_FMT_ONELINE, commit, &sb);
+	if (sb.len > 0)
+		fprintf(stderr, " %s", sb.buf);
+	fputc('\n', stderr);
+
 	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", "--quiet", NULL);
 		cp.env = child_env.argv;
 		ret = run_command(&cp);
 		if (ret)

-- 
2.17.0.rc0.231.g781580f06
Thomas Gummerer· Mar 17, 2018, 22:08 UTC · re: Thomas Gummerer · lore

[PATCH v3 2/4] worktree: be clearer when "add" dwim-ery kicks in

Currently there is no indication in the "git worktree add" output that a new branch was created. This would be especially useful information in the case where the dwim of "git worktree add <path>" kicks in, as the user didn't explicitly ask for a new branch, but we create one from them.

Print some additional output showing that a branch was created and the branch name to help the user.

This will also be useful in the next commit, which introduces a new kind of dwim-ery of checking out the branch if it exists instead of refusing to create a new worktree in that case, and where it's nice to tell the user which kind of dwim-ery kicked in.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 builtin/worktree.c | 3 +++
 1 file changed, 3 insertions(+)
Show changes to builtin/worktree.c +3 −0
diff --git a/builtin/worktree.c b/builtin/worktree.c
index e5d04f0b4b..2266c132f9 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -318,6 +318,9 @@ static int add_worktree(const char *path, const char *refname,
 	if (ret)
 		goto done;
 
+	if (opts->new_branch)
+		fprintf(stderr, _("creating new branch '%s'"), opts->new_branch);
+
 	fprintf(stderr, _("worktree HEAD is now at %s"),
 		find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
 

-- 
2.17.0.rc0.231.g781580f06
Thomas Gummerer· Mar 17, 2018, 22:08 UTC · re: Thomas Gummerer · lore

[PATCH v3 3/4] worktree: factor out dwim_branch function

Factor out a dwim_branch function, which takes care of the dwim'ery in 'git worktree add <path>'. It's not too much code currently, but we're adding a new kind of dwim in a subsequent patch, at which point it makes more sense to have it as a separate function.

Factor it out now to reduce the patch noise in the next patch.
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 builtin/worktree.c | 27 +++++++++++++++++----------
 1 file changed, 17 insertions(+), 10 deletions(-)
Show changes to builtin/worktree.c +17 −10
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 2266c132f9..52049b447a 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -367,6 +367,20 @@ static int add_worktree(const char *path, const char *refname,
 	return ret;
 }
 
+static const char *dwim_branch(const char *path, struct add_opts *opts)
+{
+	int n;
+	const char *s = worktree_basename(path, &n);
+	opts->new_branch = xstrndup(s, n);
+	if (guess_remote) {
+		struct object_id oid;
+		const char *remote =
+			unique_tracking_name(opts->new_branch, &oid);
+		return remote;
+	}
+	return NULL;
+}
+
 static int add(int ac, const char **av, const char *prefix)
 {
 	struct add_opts opts;
@@ -419,16 +433,9 @@ static int add(int ac, const char **av, const char *prefix)
 	}
 
 	if (ac < 2 && !opts.new_branch && !opts.detach) {
-		int n;
-		const char *s = worktree_basename(path, &n);
-		opts.new_branch = xstrndup(s, n);
-		if (guess_remote) {
-			struct object_id oid;
-			const char *remote =
-				unique_tracking_name(opts.new_branch, &oid);
-			if (remote)
-				branch = remote;
-		}
+		const char *dwim_branchname = dwim_branch(path, &opts);
+		if (dwim_branchname)
+			branch = dwim_branchname;
 	}
 
 	if (ac == 2 && !opts.new_branch && !opts.detach) {

-- 
2.17.0.rc0.231.g781580f06
Thomas Gummerer· Mar 17, 2018, 22:08 UTC · re: Thomas Gummerer · lore

[PATCH v3 4/4] worktree: teach "add" to check out existing branches

Currently 'git worktree add <path>' creates a new branch named after the basename of the path by default. If a branch with that name already exists, the command refuses to do anything, unless the '--force' option is given.

However we can do a little better than that, and check the branch out if it is not checked out anywhere else. This will help users who just want to check an existing branch out into a new worktree, and save a few keystrokes.

As the current behaviour is to simply 'die()' when a branch with the name of the basename of the path already exists, there are no backwards compatibility worries here.

We will still 'die()' if the branch is checked out in another worktree, unless the --force flag is passed.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 Documentation/git-worktree.txt |  9 +++++++--
 builtin/worktree.c             | 22 +++++++++++++++++++---
 t/t2025-worktree-add.sh        | 15 ++++++++++++---
 3 files changed, 38 insertions(+), 8 deletions(-)
Show changes to 3 files +38 −8

Documentation/git-worktree.txt, builtin/worktree.c, t/t2025-worktree-add.sh

diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index 41585f535d..98731b71a7 100644
--- a/Documentation/git-worktree.txt
+++ b/Documentation/git-worktree.txt
@@ -61,8 +61,13 @@ $ git worktree add --track -b <branch> <path> <remote>/<branch>
 ------------
 +
 If `<commit-ish>` is omitted and neither `-b` nor `-B` nor `--detach` used,
-then, as a convenience, a new branch based at HEAD is created automatically,
-as if `-b $(basename <path>)` was specified.
+then, as a convenience, a worktree with a branch named after
+`$(basename <path>)` (call it `<branch>`) is created.  If `<branch>`
+doesn't exist, a new branch based on HEAD is automatically created as
+if `-b <branch>` was given.  If `<branch>` exists in the repository,
+it will be checked out in the new worktree, if it's not checked out
+anywhere else, otherwise the command will refuse to create the
+worktree.
 
 list::
 
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 52049b447a..b5d273751f 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -29,6 +29,7 @@ struct add_opts {
 	int keep_locked;
 	const char *new_branch;
 	int force_new_branch;
+	int checkout_existing_branch;
 };
 
 static int show_only;
@@ -318,8 +319,11 @@ static int add_worktree(const char *path, const char *refname,
 	if (ret)
 		goto done;
 
-	if (opts->new_branch)
-		fprintf(stderr, _("creating new branch '%s'"), opts->new_branch);
+	if (opts->checkout_existing_branch)
+		fprintf(stderr, _("checking out branch '%s'"),
+			refname);
+	else if (opts->new_branch)
+		fprintf(stderr, _("creating branch '%s'"), opts->new_branch);
 
 	fprintf(stderr, _("worktree HEAD is now at %s"),
 		find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
@@ -371,7 +375,19 @@ static const char *dwim_branch(const char *path, struct add_opts *opts)
 {
 	int n;
 	const char *s = worktree_basename(path, &n);
-	opts->new_branch = xstrndup(s, n);
+	const char *branchname = xstrndup(s, n);
+	struct strbuf ref = STRBUF_INIT;
+
+	if (!strbuf_check_branch_ref(&ref, branchname) &&
+	    ref_exists(ref.buf)) {
+		*branch = branchname;
+		opts->checkout_existing_branch = 1;
+		strbuf_release(&ref);
+		UNLEAK(branchname);
+		return branchname;
+	}
+
+	opts->new_branch = branchname;
 	if (guess_remote) {
 		struct object_id oid;
 		const char *remote =
diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
index 2b95944973..721b0e4c26 100755
--- a/t/t2025-worktree-add.sh
+++ b/t/t2025-worktree-add.sh
@@ -198,13 +198,22 @@ test_expect_success '"add" with <branch> omitted' '
 	test_cmp_rev HEAD bat
 '
 
-test_expect_success '"add" auto-vivify does not clobber existing branch' '
+test_expect_success '"add" auto-vivify checks out existing branch' '
 	test_commit c1 &&
 	test_commit c2 &&
 	git branch precious HEAD~1 &&
-	test_must_fail git worktree add precious &&
+	git worktree add precious &&
 	test_cmp_rev HEAD~1 precious &&
-	test_path_is_missing precious
+	(
+		cd precious &&
+		test_cmp_rev precious HEAD
+	)
+'
+
+test_expect_success '"add" auto-vivify fails with checked out branch' '
+	git checkout -b test-branch &&
+	test_must_fail git worktree add test-branch &&
+	test_path_is_missing test-branch
 '
 
 test_expect_success '"add" no auto-vivify with --detach and <branch> omitted' '

-- 
2.17.0.rc0.231.g781580f06
Thomas Gummerer· Mar 17, 2018, 22:22 UTC · re: Thomas Gummerer · lore

[PATCH v4 0/4] worktree: teach "add" to check out existing branches

Please ignore v3 of this series, I just noticed that I botched the last commit :( sorry about the noise.

Previous rounds (other than v3) are at <20180121120208.12760-1-t.gummerer@gmail.com> and <20180204221305.28300-1-t.gummerer@gmail.com>. Thanks Duy, Eric and Junio for the comments on the previous round.

This round improves the end user facing messages, and factors out a dwim_branch function as suggested by Duy.

Interdiff between this and v2 below:
Show changes to builtin/worktree.c +31 −26
diff --git a/builtin/worktree.c b/builtin/worktree.c
index ea420bb90b..df5c0427ba 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -304,8 +304,6 @@ static int add_worktree(const char *path, const char *refname,
 	strbuf_addf(&sb, "%s/commondir", sb_repo.buf);
 	write_file(sb.buf, "../..");
 
-	fprintf(stderr, _("Preparing %s (identifier %s)"), path, name);
-
 	argv_array_pushf(&child_env, "%s=%s", GIT_DIR_ENVIRONMENT, sb_git.buf);
 	argv_array_pushf(&child_env, "%s=%s", GIT_WORK_TREE_ENVIRONMENT, path);
 	cp.git_cmd = 1;
@@ -322,12 +320,12 @@ static int add_worktree(const char *path, const char *refname,
 		goto done;
 
 	if (opts->checkout_existing_branch)
-		fprintf(stderr, _(", checking out existing branch '%s'"),
+		fprintf(stderr, _("checking out branch '%s'"),
 			refname);
 	else if (opts->new_branch)
-		fprintf(stderr, _(", creating new branch '%s'"), opts->new_branch);
+		fprintf(stderr, _("creating branch '%s'"), opts->new_branch);
 
-	fprintf(stderr, _(", setting HEAD to %s"),
+	fprintf(stderr, _("worktree HEAD is now at %s"),
 		find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
 
 	strbuf_reset(&sb);
@@ -373,6 +371,31 @@ static int add_worktree(const char *path, const char *refname,
 	return ret;
 }
 
+static const char *dwim_branch(const char *path, struct add_opts *opts)
+{
+	int n;
+	const char *s = worktree_basename(path, &n);
+	const char *branchname = xstrndup(s, n);
+	struct strbuf ref = STRBUF_INIT;
+
+	if (!strbuf_check_branch_ref(&ref, branchname) &&
+	    ref_exists(ref.buf)) {
+		opts->checkout_existing_branch = 1;
+		strbuf_release(&ref);
+		UNLEAK(branchname);
+		return branchname;
+	}
+
+	opts->new_branch = branchname;
+	if (guess_remote) {
+		struct object_id oid;
+		const char *remote =
+			unique_tracking_name(opts->new_branch, &oid);
+		return remote;
+	}
+	return NULL;
+}
+
 static int add(int ac, const char **av, const char *prefix)
 {
 	struct add_opts opts;
@@ -425,27 +448,9 @@ static int add(int ac, const char **av, const char *prefix)
 	}
 
 	if (ac < 2 && !opts.new_branch && !opts.detach) {
-		int n;
-		const char *s = worktree_basename(path, &n);
-		const char *branchname = xstrndup(s, n);
-		struct strbuf ref = STRBUF_INIT;
-
-		if (!strbuf_check_branch_ref(&ref, branchname) &&
-		    ref_exists(ref.buf)) {
-			branch = branchname;
-			opts.checkout_existing_branch = 1;
-			UNLEAK(branch);
-		} else {
-			opts.new_branch = branchname;
-			if (guess_remote) {
-				struct object_id oid;
-				const char *remote =
-					unique_tracking_name(opts.new_branch, &oid);
-				if (remote)
-					branch = remote;
-			}
-		}
-		strbuf_release(&ref);
+		const char *dwim_branchname = dwim_branch(path, &opts);
+		if (dwim_branchname)
+			branch = dwim_branchname;
 	}
 
 	if (ac == 2 && !opts.new_branch && !opts.detach) {

Thomas Gummerer (4):
  worktree: improve message when creating a new worktree
  worktree: be clearer when "add" dwim-ery kicks in
  worktree: factor out dwim_branch function
  worktree: teach "add" to check out existing branches

 Documentation/git-worktree.txt |  9 ++++--
 builtin/worktree.c             | 58 ++++++++++++++++++++++++++--------
 t/t2025-worktree-add.sh        | 15 +++++++--
 3 files changed, 64 insertions(+), 18 deletions(-)

-- 
2.17.0.rc0.231.g781580f06
Thomas Gummerer· Mar 17, 2018, 22:22 UTC · re: Thomas Gummerer · lore

[PATCH v4 1/4] worktree: improve message when creating a new worktree

Currently 'git worktree add' produces output like the following, when '--no-checkout' is not given:

    Preparing foo (identifier foo)
    HEAD is now at 26da330922 <title>

where the first line is written to stderr, and the second line coming from 'git reset --hard' is written to stdout, even though both lines are supposed to tell the user what has happened. In addition to someone not familiar with 'git worktree', this might seem as if the current HEAD was modified, not the HEAD in the new working tree.

If the '--no-checkout' flag is given, the output of 'git worktree add' is just:

    Preparing foo (identifier foo)
even though the HEAD is set to a commit, which is just not checked out.

The identifier is also not particularly relevant for the user at the moment, as it's only used internally to distinguish between different worktrees that have the same $(basename <path>).

Fix these inconsistencies, and no longer show the identifier by making the 'git reset --hard' call quiet, and printing the message directly from the builtin command instead.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 builtin/worktree.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)
Show changes to builtin/worktree.c +10 −3
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 7cef5b120b..e5d04f0b4b 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -303,8 +303,6 @@ static int add_worktree(const char *path, const char *refname,
 	strbuf_addf(&sb, "%s/commondir", sb_repo.buf);
 	write_file(sb.buf, "../..");
 
-	fprintf_ln(stderr, _("Preparing %s (identifier %s)"), path, name);
-
 	argv_array_pushf(&child_env, "%s=%s", GIT_DIR_ENVIRONMENT, sb_git.buf);
 	argv_array_pushf(&child_env, "%s=%s", GIT_WORK_TREE_ENVIRONMENT, path);
 	cp.git_cmd = 1;
@@ -320,10 +318,19 @@ static int add_worktree(const char *path, const char *refname,
 	if (ret)
 		goto done;
 
+	fprintf(stderr, _("worktree HEAD is now at %s"),
+		find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
+
+	strbuf_reset(&sb);
+	pp_commit_easy(CMIT_FMT_ONELINE, commit, &sb);
+	if (sb.len > 0)
+		fprintf(stderr, " %s", sb.buf);
+	fputc('\n', stderr);
+
 	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", "--quiet", NULL);
 		cp.env = child_env.argv;
 		ret = run_command(&cp);
 		if (ret)

-- 
2.17.0.rc0.231.g781580f06
Duy Nguyen· Mar 19, 2018, 17:11 UTC · re: Thomas Gummerer · lore

Re: [PATCH v4 1/4] worktree: improve message when creating a new worktree

On Sat, Mar 17, 2018 at 11:22 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
Show 50 quoted lines
> Currently 'git worktree add' produces output like the following, when
> '--no-checkout' is not given:
>
>     Preparing foo (identifier foo)
>     HEAD is now at 26da330922 <title>
>
> where the first line is written to stderr, and the second line coming
> from 'git reset --hard' is written to stdout, even though both lines are
> supposed to tell the user what has happened.  In addition to someone not
> familiar with 'git worktree', this might seem as if the current HEAD was
> modified, not the HEAD in the new working tree.
>
> If the '--no-checkout' flag is given, the output of 'git worktree add'
> is just:
>
>     Preparing foo (identifier foo)
>
> even though the HEAD is set to a commit, which is just not checked out.
>
> The identifier is also not particularly relevant for the user at the
> moment, as it's only used internally to distinguish between different
> worktrees that have the same $(basename <path>).
>
> Fix these inconsistencies, and no longer show the identifier by making
> the 'git reset --hard' call quiet, and printing the message directly
> from the builtin command instead.
>
> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
> ---
>  builtin/worktree.c | 13 ++++++++++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/builtin/worktree.c b/builtin/worktree.c
> index 7cef5b120b..e5d04f0b4b 100644
> --- a/builtin/worktree.c
> +++ b/builtin/worktree.c
> @@ -303,8 +303,6 @@ static int add_worktree(const char *path, const char *refname,
>         strbuf_addf(&sb, "%s/commondir", sb_repo.buf);
>         write_file(sb.buf, "../..");
>
> -       fprintf_ln(stderr, _("Preparing %s (identifier %s)"), path, name);
> -
>         argv_array_pushf(&child_env, "%s=%s", GIT_DIR_ENVIRONMENT, sb_git.buf);
>         argv_array_pushf(&child_env, "%s=%s", GIT_WORK_TREE_ENVIRONMENT, path);
>         cp.git_cmd = 1;
> @@ -320,10 +318,19 @@ static int add_worktree(const char *path, const char *refname,
>         if (ret)
>                 goto done;
>
> +       fprintf(stderr, _("worktree HEAD is now at %s"),

We use the term "working tree" for UI and documents. "worktree" is only used in code comments and stuff.

Show 19 quoted lines
> +               find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
> +
> +       strbuf_reset(&sb);
> +       pp_commit_easy(CMIT_FMT_ONELINE, commit, &sb);
> +       if (sb.len > 0)
> +               fprintf(stderr, " %s", sb.buf);
> +       fputc('\n', stderr);
> +
>         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", "--quiet", NULL);
>                 cp.env = child_env.argv;
>                 ret = run_command(&cp);
>                 if (ret)
> --
> 2.17.0.rc0.231.g781580f06
>
-- 
Duy
Junio C Hamano· Mar 19, 2018, 18:09 UTC · re: Duy Nguyen · lore

Re: [PATCH v4 1/4] worktree: improve message when creating a new worktree

Duy Nguyen <pclouds@gmail.com> writes:
Show 8 quoted lines
>> @@ -320,10 +318,19 @@ static int add_worktree(const char *path, const char *refname,
>>         if (ret)
>>                 goto done;
>>
>> +       fprintf(stderr, _("worktree HEAD is now at %s"),
>
> We use the term "working tree" for UI and documents. "worktree" is
> only used in code comments and stuff.

Hmph, that is a bit different from what I recall. "working tree" is the phrase we have used and we still use to refer to those things that are checked out (as opposed to the in-repo data). We say "worktree" when we want to stress the fact that we are talking about a single instance among possibly multiple instances of the "working tree" that are associated to a single repository.

Technically speaking, the traditional "working tree" is everything in the directory immediately above ".git/" plus ".git/index"; a single "worktree" consists of a bit more, as we have to count per worktree states like .git/rebase-apply/ and .git/refs/bisect/ as part of it.

And from that point of view, HEAD is one of those per worktree states, so...

Eric Sunshine· Mar 20, 2018, 06:37 UTC · re: Thomas Gummerer · lore

Re: [PATCH v4 1/4] worktree: improve message when creating a new worktree

On Sat, Mar 17, 2018 at 6:22 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
Show 13 quoted lines
> [...]
> Fix these inconsistencies, and no longer show the identifier by making
> the 'git reset --hard' call quiet, and printing the message directly
> from the builtin command instead.
>
> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
> ---
> diff --git a/builtin/worktree.c b/builtin/worktree.c
> @@ -303,8 +303,6 @@ static int add_worktree(const char *path, const char *refname,
>         strbuf_addf(&sb, "%s/commondir", sb_repo.buf);
>         write_file(sb.buf, "../..");
>
> -       fprintf_ln(stderr, _("Preparing %s (identifier %s)"), path, name);

A minor regression with this change is that error messages from git-update-ref or git-symbolic-ref -- which could be emitted after this point but before the new "worktree HEAD is now at..." message -- are now somewhat orphaned. I'm not sure that it matters, though.

Show 6 quoted lines
>         argv_array_pushf(&child_env, "%s=%s", GIT_DIR_ENVIRONMENT, sb_git.buf);
>         argv_array_pushf(&child_env, "%s=%s", GIT_WORK_TREE_ENVIRONMENT, path);
>         cp.git_cmd = 1;
> @@ -320,10 +318,19 @@ static int add_worktree(const char *path, const char *refname,
> +       fprintf(stderr, _("worktree HEAD is now at %s"),
> +               find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));

I wonder if this should say "new worktree HEAD is now at..." to clearly indicate that it is talking about HEAD in the _new_ worktree, not HEAD in the current worktree.

Show 5 quoted lines
> +       strbuf_reset(&sb);
> +       pp_commit_easy(CMIT_FMT_ONELINE, commit, &sb);
> +       if (sb.len > 0)
> +               fprintf(stderr, " %s", sb.buf);
> +       fputc('\n', stderr);
Thomas Gummerer· Mar 24, 2018, 20:34 UTC · re: Eric Sunshine · lore

Re: [PATCH v4 1/4] worktree: improve message when creating a new worktree

On 03/20, Eric Sunshine wrote:
Show 19 quoted lines
> On Sat, Mar 17, 2018 at 6:22 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
> > [...]
> > Fix these inconsistencies, and no longer show the identifier by making
> > the 'git reset --hard' call quiet, and printing the message directly
> > from the builtin command instead.
> >
> > Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
> > ---
> > diff --git a/builtin/worktree.c b/builtin/worktree.c
> > @@ -303,8 +303,6 @@ static int add_worktree(const char *path, const char *refname,
> >         strbuf_addf(&sb, "%s/commondir", sb_repo.buf);
> >         write_file(sb.buf, "../..");
> >
> > -       fprintf_ln(stderr, _("Preparing %s (identifier %s)"), path, name);
> 
> A minor regression with this change is that error messages from
> git-update-ref or git-symbolic-ref -- which could be emitted after
> this point but before the new "worktree HEAD is now at..." message --
> are now somewhat orphaned. I'm not sure that it matters, though.

If those commands fail, we would now not print the "worktree HEAD is now at..." message, but go directly to "done", and clean up the working tree.

So while we no longer emit the "Preparing worktree" header, the user should still be aware that they are creating a new worktree, and that the error happened while creating a new worktree. From a (admittedly very quick) look the error messages would all make sense in this context, without an additional message.

Printing the "worktree HEAD is now at ..." message before that wouldn't make much sense, as we may not even have a new working tree at the end. We could add the message back, but that would also put us back at three lines of output. I think I prefer the more concise version here in the normal case, and I think we can live with the slight regression. But if others have a strong preference for the current way I'm happy to add that message back.

Show 10 quoted lines
> >         argv_array_pushf(&child_env, "%s=%s", GIT_DIR_ENVIRONMENT, sb_git.buf);
> >         argv_array_pushf(&child_env, "%s=%s", GIT_WORK_TREE_ENVIRONMENT, path);
> >         cp.git_cmd = 1;
> > @@ -320,10 +318,19 @@ static int add_worktree(const char *path, const char *refname,
> > +       fprintf(stderr, _("worktree HEAD is now at %s"),
> > +               find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
> 
> I wonder if this should say "new worktree HEAD is now at..." to
> clearly indicate that it is talking about HEAD in the _new_ worktree,
> not HEAD in the current worktree.
Yeah I aggree that's nicer.  Will change.
Show 5 quoted lines
> > +       strbuf_reset(&sb);
> > +       pp_commit_easy(CMIT_FMT_ONELINE, commit, &sb);
> > +       if (sb.len > 0)
> > +               fprintf(stderr, " %s", sb.buf);
> > +       fputc('\n', stderr);
Thomas Gummerer· Mar 17, 2018, 22:22 UTC · re: Thomas Gummerer · lore

[PATCH v4 3/4] worktree: factor out dwim_branch function

Factor out a dwim_branch function, which takes care of the dwim'ery in 'git worktree add <path>'. It's not too much code currently, but we're adding a new kind of dwim in a subsequent patch, at which point it makes more sense to have it as a separate function.

Factor it out now to reduce the patch noise in the next patch.
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 builtin/worktree.c | 27 +++++++++++++++++----------
 1 file changed, 17 insertions(+), 10 deletions(-)
Show changes to builtin/worktree.c +17 −10
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 2266c132f9..52049b447a 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -367,6 +367,20 @@ static int add_worktree(const char *path, const char *refname,
 	return ret;
 }
 
+static const char *dwim_branch(const char *path, struct add_opts *opts)
+{
+	int n;
+	const char *s = worktree_basename(path, &n);
+	opts->new_branch = xstrndup(s, n);
+	if (guess_remote) {
+		struct object_id oid;
+		const char *remote =
+			unique_tracking_name(opts->new_branch, &oid);
+		return remote;
+	}
+	return NULL;
+}
+
 static int add(int ac, const char **av, const char *prefix)
 {
 	struct add_opts opts;
@@ -419,16 +433,9 @@ static int add(int ac, const char **av, const char *prefix)
 	}
 
 	if (ac < 2 && !opts.new_branch && !opts.detach) {
-		int n;
-		const char *s = worktree_basename(path, &n);
-		opts.new_branch = xstrndup(s, n);
-		if (guess_remote) {
-			struct object_id oid;
-			const char *remote =
-				unique_tracking_name(opts.new_branch, &oid);
-			if (remote)
-				branch = remote;
-		}
+		const char *dwim_branchname = dwim_branch(path, &opts);
+		if (dwim_branchname)
+			branch = dwim_branchname;
 	}
 
 	if (ac == 2 && !opts.new_branch && !opts.detach) {

-- 
2.17.0.rc0.231.g781580f06
Thomas Gummerer· Mar 17, 2018, 22:22 UTC · re: Thomas Gummerer · lore

[PATCH v4 2/4] worktree: be clearer when "add" dwim-ery kicks in

Currently there is no indication in the "git worktree add" output that a new branch was created. This would be especially useful information in the case where the dwim of "git worktree add <path>" kicks in, as the user didn't explicitly ask for a new branch, but we create one from them.

Print some additional output showing that a branch was created and the branch name to help the user.

This will also be useful in the next commit, which introduces a new kind of dwim-ery of checking out the branch if it exists instead of refusing to create a new worktree in that case, and where it's nice to tell the user which kind of dwim-ery kicked in.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 builtin/worktree.c | 3 +++
 1 file changed, 3 insertions(+)
Show changes to builtin/worktree.c +3 −0
diff --git a/builtin/worktree.c b/builtin/worktree.c
index e5d04f0b4b..2266c132f9 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -318,6 +318,9 @@ static int add_worktree(const char *path, const char *refname,
 	if (ret)
 		goto done;
 
+	if (opts->new_branch)
+		fprintf(stderr, _("creating new branch '%s'"), opts->new_branch);
+
 	fprintf(stderr, _("worktree HEAD is now at %s"),
 		find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
 

-- 
2.17.0.rc0.231.g781580f06
Eric Sunshine· Mar 20, 2018, 06:40 UTC · re: Thomas Gummerer · lore

Re: [PATCH v4 2/4] worktree: be clearer when "add" dwim-ery kicks in

On Sat, Mar 17, 2018 at 6:22 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
Show 8 quoted lines
> Currently there is no indication in the "git worktree add" output that
> a new branch was created.  This would be especially useful information
> in the case where the dwim of "git worktree add <path>" kicks in, as the
> user didn't explicitly ask for a new branch, but we create one from
> them.
>
> Print some additional output showing that a branch was created and the
> branch name to help the user.
Good idea.
Show 6 quoted lines
> This will also be useful in the next commit, which introduces a new kind
> of dwim-ery of checking out the branch if it exists instead of refusing
> to create a new worktree in that case, and where it's nice to tell the
> user which kind of dwim-ery kicked in.
>
> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Eric Sunshine· Mar 20, 2018, 07:26 UTC · re: Thomas Gummerer · lore

Re: [PATCH v4 2/4] worktree: be clearer when "add" dwim-ery kicks in

On Sat, Mar 17, 2018 at 6:22 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
Show 18 quoted lines
> Currently there is no indication in the "git worktree add" output that
> a new branch was created.  This would be especially useful information
> in the case where the dwim of "git worktree add <path>" kicks in, as the
> user didn't explicitly ask for a new branch, but we create one from
> them.
>
> Print some additional output showing that a branch was created and the
> branch name to help the user.
> [...]
> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
> ---
> diff --git a/builtin/worktree.c b/builtin/worktree.c
> @@ -318,6 +318,9 @@ static int add_worktree(const char *path, const char *refname,
> +       if (opts->new_branch)
> +               fprintf(stderr, _("creating new branch '%s'"), opts->new_branch);
> +
>         fprintf(stderr, _("worktree HEAD is now at %s"),
>                 find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));

The "creating" message is missing a newline, which results in rather ugly output:

    creating new branch 'foo'worktree HEAD is now at ...
Eric Sunshine· Mar 20, 2018, 07:32 UTC · re: Eric Sunshine · lore

Re: [PATCH v4 2/4] worktree: be clearer when "add" dwim-ery kicks in

On Tue, Mar 20, 2018 at 3:26 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
Show 24 quoted lines
> On Sat, Mar 17, 2018 at 6:22 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
>> Currently there is no indication in the "git worktree add" output that
>> a new branch was created.  This would be especially useful information
>> in the case where the dwim of "git worktree add <path>" kicks in, as the
>> user didn't explicitly ask for a new branch, but we create one from
>> them.
>>
>> Print some additional output showing that a branch was created and the
>> branch name to help the user.
>> [...]
>> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
>> ---
>> diff --git a/builtin/worktree.c b/builtin/worktree.c
>> @@ -318,6 +318,9 @@ static int add_worktree(const char *path, const char *refname,
>> +       if (opts->new_branch)
>> +               fprintf(stderr, _("creating new branch '%s'"), opts->new_branch);
>> +
>>         fprintf(stderr, _("worktree HEAD is now at %s"),
>>                 find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
>
> The "creating" message is missing a newline, which results in rather
> ugly output:
>
>     creating new branch 'foo'worktree HEAD is now at ...

Also, I believe that the agreement[1] was that this message should say merely "creating branch", not "creating _new_ branch". And, indeed, patch 4/4 stealthily drops "new" from the message, but it really ought to be introduced with correct text in this patch, not fixed by 4/4.

[1]: https://public-inbox.org/git/xmqqh8qv9ojb.fsf@gitster-ct.c.googlers.com/
Thomas Gummerer· Mar 24, 2018, 20:35 UTC · re: Eric Sunshine · lore

Re: [PATCH v4 2/4] worktree: be clearer when "add" dwim-ery kicks in

On 03/20, Eric Sunshine wrote:
Show 30 quoted lines
> On Tue, Mar 20, 2018 at 3:26 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> > On Sat, Mar 17, 2018 at 6:22 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
> >> Currently there is no indication in the "git worktree add" output that
> >> a new branch was created.  This would be especially useful information
> >> in the case where the dwim of "git worktree add <path>" kicks in, as the
> >> user didn't explicitly ask for a new branch, but we create one from
> >> them.
> >>
> >> Print some additional output showing that a branch was created and the
> >> branch name to help the user.
> >> [...]
> >> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
> >> ---
> >> diff --git a/builtin/worktree.c b/builtin/worktree.c
> >> @@ -318,6 +318,9 @@ static int add_worktree(const char *path, const char *refname,
> >> +       if (opts->new_branch)
> >> +               fprintf(stderr, _("creating new branch '%s'"), opts->new_branch);
> >> +
> >>         fprintf(stderr, _("worktree HEAD is now at %s"),
> >>                 find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
> >
> > The "creating" message is missing a newline, which results in rather
> > ugly output:
> >
> >     creating new branch 'foo'worktree HEAD is now at ...
> 
> Also, I believe that the agreement[1] was that this message should say
> merely "creating branch", not "creating _new_ branch". And, indeed,
> patch 4/4 stealthily drops "new" from the message, but it really ought
> to be introduced with correct text in this patch, not fixed by 4/4.
Ah yeah thanks for catching those, will fix.
> [1]: https://public-inbox.org/git/xmqqh8qv9ojb.fsf@gitster-ct.c.googlers.com/
Thomas Gummerer· Mar 17, 2018, 22:22 UTC · re: Thomas Gummerer · lore

[PATCH v4 4/4] worktree: teach "add" to check out existing branches

Currently 'git worktree add <path>' creates a new branch named after the basename of the path by default. If a branch with that name already exists, the command refuses to do anything, unless the '--force' option is given.

However we can do a little better than that, and check the branch out if it is not checked out anywhere else. This will help users who just want to check an existing branch out into a new worktree, and save a few keystrokes.

As the current behaviour is to simply 'die()' when a branch with the name of the basename of the path already exists, there are no backwards compatibility worries here.

We will still 'die()' if the branch is checked out in another worktree, unless the --force flag is passed.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 Documentation/git-worktree.txt |  9 +++++++--
 builtin/worktree.c             | 21 ++++++++++++++++++---
 t/t2025-worktree-add.sh        | 15 ++++++++++++---
 3 files changed, 37 insertions(+), 8 deletions(-)
Show changes to 3 files +37 −8

Documentation/git-worktree.txt, builtin/worktree.c, t/t2025-worktree-add.sh

diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index 41585f535d..98731b71a7 100644
--- a/Documentation/git-worktree.txt
+++ b/Documentation/git-worktree.txt
@@ -61,8 +61,13 @@ $ git worktree add --track -b <branch> <path> <remote>/<branch>
 ------------
 +
 If `<commit-ish>` is omitted and neither `-b` nor `-B` nor `--detach` used,
-then, as a convenience, a new branch based at HEAD is created automatically,
-as if `-b $(basename <path>)` was specified.
+then, as a convenience, a worktree with a branch named after
+`$(basename <path>)` (call it `<branch>`) is created.  If `<branch>`
+doesn't exist, a new branch based on HEAD is automatically created as
+if `-b <branch>` was given.  If `<branch>` exists in the repository,
+it will be checked out in the new worktree, if it's not checked out
+anywhere else, otherwise the command will refuse to create the
+worktree.
 
 list::
 
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 52049b447a..df5c0427ba 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -29,6 +29,7 @@ struct add_opts {
 	int keep_locked;
 	const char *new_branch;
 	int force_new_branch;
+	int checkout_existing_branch;
 };
 
 static int show_only;
@@ -318,8 +319,11 @@ static int add_worktree(const char *path, const char *refname,
 	if (ret)
 		goto done;
 
-	if (opts->new_branch)
-		fprintf(stderr, _("creating new branch '%s'"), opts->new_branch);
+	if (opts->checkout_existing_branch)
+		fprintf(stderr, _("checking out branch '%s'"),
+			refname);
+	else if (opts->new_branch)
+		fprintf(stderr, _("creating branch '%s'"), opts->new_branch);
 
 	fprintf(stderr, _("worktree HEAD is now at %s"),
 		find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
@@ -371,7 +375,18 @@ static const char *dwim_branch(const char *path, struct add_opts *opts)
 {
 	int n;
 	const char *s = worktree_basename(path, &n);
-	opts->new_branch = xstrndup(s, n);
+	const char *branchname = xstrndup(s, n);
+	struct strbuf ref = STRBUF_INIT;
+
+	if (!strbuf_check_branch_ref(&ref, branchname) &&
+	    ref_exists(ref.buf)) {
+		opts->checkout_existing_branch = 1;
+		strbuf_release(&ref);
+		UNLEAK(branchname);
+		return branchname;
+	}
+
+	opts->new_branch = branchname;
 	if (guess_remote) {
 		struct object_id oid;
 		const char *remote =
diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
index 2b95944973..721b0e4c26 100755
--- a/t/t2025-worktree-add.sh
+++ b/t/t2025-worktree-add.sh
@@ -198,13 +198,22 @@ test_expect_success '"add" with <branch> omitted' '
 	test_cmp_rev HEAD bat
 '
 
-test_expect_success '"add" auto-vivify does not clobber existing branch' '
+test_expect_success '"add" auto-vivify checks out existing branch' '
 	test_commit c1 &&
 	test_commit c2 &&
 	git branch precious HEAD~1 &&
-	test_must_fail git worktree add precious &&
+	git worktree add precious &&
 	test_cmp_rev HEAD~1 precious &&
-	test_path_is_missing precious
+	(
+		cd precious &&
+		test_cmp_rev precious HEAD
+	)
+'
+
+test_expect_success '"add" auto-vivify fails with checked out branch' '
+	git checkout -b test-branch &&
+	test_must_fail git worktree add test-branch &&
+	test_path_is_missing test-branch
 '
 
 test_expect_success '"add" no auto-vivify with --detach and <branch> omitted' '

-- 
2.17.0.rc0.231.g781580f06
Eric Sunshine· Mar 20, 2018, 08:02 UTC · re: Thomas Gummerer · lore

Re: [PATCH v4 4/4] worktree: teach "add" to check out existing branches

On Sat, Mar 17, 2018 at 6:22 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
Show 23 quoted lines
> [...]
> However we can do a little better than that, and check the branch out if
> it is not checked out anywhere else.  This will help users who just want
> to check an existing branch out into a new worktree, and save a few
> keystrokes.
> [...]
> We will still 'die()' if the branch is checked out in another worktree,
> unless the --force flag is passed.
>
> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
> ---
> diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
> @@ -61,8 +61,13 @@ $ git worktree add --track -b <branch> <path> <remote>/<branch>
>  If `<commit-ish>` is omitted and neither `-b` nor `-B` nor `--detach` used,
> -then, as a convenience, a new branch based at HEAD is created automatically,
> -as if `-b $(basename <path>)` was specified.
> +then, as a convenience, a worktree with a branch named after
> +`$(basename <path>)` (call it `<branch>`) is created.  If `<branch>`
> +doesn't exist, a new branch based on HEAD is automatically created as
> +if `-b <branch>` was given.  If `<branch>` exists in the repository,
> +it will be checked out in the new worktree, if it's not checked out
> +anywhere else, otherwise the command will refuse to create the
> +worktree.
Should this mention --force?
    ... refuse to create the worktree (unless --force is used).
Show 6 quoted lines
> diff --git a/builtin/worktree.c b/builtin/worktree.c
> @@ -29,6 +29,7 @@ struct add_opts {
>         int keep_locked;
>         const char *new_branch;
>         int force_new_branch;
> +       int checkout_existing_branch;

As 'force_new_branch' and 'checkout_existing_branch' are mutually exclusive, I wonder if they should be combined into an enum to make it easier to reason about.

Show 6 quoted lines
> @@ -318,8 +319,11 @@ static int add_worktree(const char *path, const char *refname,
> -       if (opts->new_branch)
> -               fprintf(stderr, _("creating new branch '%s'"), opts->new_branch);
> +       if (opts->checkout_existing_branch)
> +               fprintf(stderr, _("checking out branch '%s'"),
> +                       refname);

As with "creating branch" in 2/4, "checking out branch..." here is missing a newline.

Show 21 quoted lines
> +       else if (opts->new_branch)
> +               fprintf(stderr, _("creating branch '%s'"), opts->new_branch);
>
>         fprintf(stderr, _("worktree HEAD is now at %s"),
>                 find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
> diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
> @@ -198,13 +198,22 @@ test_expect_success '"add" with <branch> omitted' '
> -test_expect_success '"add" auto-vivify does not clobber existing branch' '
> +test_expect_success '"add" auto-vivify checks out existing branch' '
>         test_commit c1 &&
>         test_commit c2 &&
>         git branch precious HEAD~1 &&
> -       test_must_fail git worktree add precious &&
> +       git worktree add precious &&
>         test_cmp_rev HEAD~1 precious &&
> -       test_path_is_missing precious
> +       (
> +               cd precious &&
> +               test_cmp_rev precious HEAD
> +       )
> +'

This test is no longer checking auto-vivification ("bringing a new branch to life automatically"), but rather branch name inference, so the title is now misleading. Perhaps retitle it to '"add" checks out existing branch of dwim'd name' or something.

(The name "precious" is also now misleading since it's no longer checking that a precious branch does not get clobbered, however, changing the name would make the diff unnecessarily noisy, so it's probably okay as is.)

Show 5 quoted lines
> +test_expect_success '"add" auto-vivify fails with checked out branch' '
> +       git checkout -b test-branch &&
> +       test_must_fail git worktree add test-branch &&
> +       test_path_is_missing test-branch
>  '

Should we also have a corresponding test that this "fail" can be overridden by --force? (I realize that --force is tested elsewhere, but only with an explicitly-provided branch name, whereas this dwims the branch name.)

Thomas Gummerer· Mar 24, 2018, 21:00 UTC · re: Eric Sunshine · lore

Re: [PATCH v4 4/4] worktree: teach "add" to check out existing branches

On 03/20, Eric Sunshine wrote:
Show 28 quoted lines
> On Sat, Mar 17, 2018 at 6:22 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
> > [...]
> > However we can do a little better than that, and check the branch out if
> > it is not checked out anywhere else.  This will help users who just want
> > to check an existing branch out into a new worktree, and save a few
> > keystrokes.
> > [...]
> > We will still 'die()' if the branch is checked out in another worktree,
> > unless the --force flag is passed.
> >
> > Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
> > ---
> > diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
> > @@ -61,8 +61,13 @@ $ git worktree add --track -b <branch> <path> <remote>/<branch>
> >  If `<commit-ish>` is omitted and neither `-b` nor `-B` nor `--detach` used,
> > -then, as a convenience, a new branch based at HEAD is created automatically,
> > -as if `-b $(basename <path>)` was specified.
> > +then, as a convenience, a worktree with a branch named after
> > +`$(basename <path>)` (call it `<branch>`) is created.  If `<branch>`
> > +doesn't exist, a new branch based on HEAD is automatically created as
> > +if `-b <branch>` was given.  If `<branch>` exists in the repository,
> > +it will be checked out in the new worktree, if it's not checked out
> > +anywhere else, otherwise the command will refuse to create the
> > +worktree.
> 
> Should this mention --force?
> 
>     ... refuse to create the worktree (unless --force is used).
Yeah, will add.
Show 10 quoted lines
> > diff --git a/builtin/worktree.c b/builtin/worktree.c
> > @@ -29,6 +29,7 @@ struct add_opts {
> >         int keep_locked;
> >         const char *new_branch;
> >         int force_new_branch;
> > +       int checkout_existing_branch;
> 
> As 'force_new_branch' and 'checkout_existing_branch' are mutually
> exclusive, I wonder if they should be combined into an enum to make it
> easier to reason about.

I gave this a try, but I'm not sure the end result is nicer. The problem is that 'new_branch' and 'force_new_branch' both are mutually exclusive with 'checkout_existing_branch', but 'force_new_branch' is a "superset" of 'new_branch'.

I can't seem to think of a nice way to encode that, especially not without duplicating information we're already carrying in 'new_branch'. Looking at the code however I see that 'force_new_branch' is already only duplicating information that we already have in a variable in the same function. I think just removing that duplication and keeping the 'checkout_existing_branch' variable in the 'add_opts' would make most sense.

Show 9 quoted lines
> > @@ -318,8 +319,11 @@ static int add_worktree(const char *path, const char *refname,
> > -       if (opts->new_branch)
> > -               fprintf(stderr, _("creating new branch '%s'"), opts->new_branch);
> > +       if (opts->checkout_existing_branch)
> > +               fprintf(stderr, _("checking out branch '%s'"),
> > +                       refname);
> 
> As with "creating branch" in 2/4, "checking out branch..." here is
> missing a newline.
Thanks will add.
Show 31 quoted lines
> > +       else if (opts->new_branch)
> > +               fprintf(stderr, _("creating branch '%s'"), opts->new_branch);
> >
> >         fprintf(stderr, _("worktree HEAD is now at %s"),
> >                 find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
> > diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
> > @@ -198,13 +198,22 @@ test_expect_success '"add" with <branch> omitted' '
> > -test_expect_success '"add" auto-vivify does not clobber existing branch' '
> > +test_expect_success '"add" auto-vivify checks out existing branch' '
> >         test_commit c1 &&
> >         test_commit c2 &&
> >         git branch precious HEAD~1 &&
> > -       test_must_fail git worktree add precious &&
> > +       git worktree add precious &&
> >         test_cmp_rev HEAD~1 precious &&
> > -       test_path_is_missing precious
> > +       (
> > +               cd precious &&
> > +               test_cmp_rev precious HEAD
> > +       )
> > +'
> 
> This test is no longer checking auto-vivification ("bringing a new
> branch to life automatically"), but rather branch name inference, so
> the title is now misleading. Perhaps retitle it to '"add" checks out
> existing branch of dwim'd name' or something.
> 
> (The name "precious" is also now misleading since it's no longer
> checking that a precious branch does not get clobbered, however,
> changing the name would make the diff unnecessarily noisy, so it's
> probably okay as is.)

Good point. I can add an additional patch with that rename, so the changes here stay more obvious, but the end result would still end up less confusing.

Show 10 quoted lines
> > +test_expect_success '"add" auto-vivify fails with checked out branch' '
> > +       git checkout -b test-branch &&
> > +       test_must_fail git worktree add test-branch &&
> > +       test_path_is_missing test-branch
> >  '
> 
> Should we also have a corresponding test that this "fail" can be
> overridden by --force? (I realize that --force is tested elsewhere,
> but only with an explicitly-provided branch name, whereas this dwims
> the branch name.)
Yes, will add a test.  Thanks for your review!
Thomas Gummerer· Mar 25, 2018, 13:49 UTC · re: Thomas Gummerer · lore

[PATCH v5 0/6] worktree: teach "add" to check out existing branches

Thanks Eric for the review of the previous round and Duy and Junio for additional comments.

Previous rounds are at <20180121120208.12760-1-t.gummerer@gmail.com>, <20180204221305.28300-1-t.gummerer@gmail.com>, <20180317220830.30963-1-t.gummerer@gmail.com> and <20180317222219.4940-1-t.gummerer@gmail.com>.

This round should address all of Eric's comments from the previous round.

As explained in more detail in a reply to the review comment directly, I did not add an enum to 'struct add_opts', for 'force_new_branch' and 'checkout_existing_branch', but instead removed 'force_new_branch' from the struct as it's not required.

The rest of the updates are mainly in the user facing messages, documentation and one added test.

Interdiff below:
Show changes to 3 files +17 −15

Documentation/git-worktree.txt, builtin/worktree.c, t/t2025-worktree-add.sh

diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index 98731b71a7..eaa6bf713f 100644
--- a/Documentation/git-worktree.txt
+++ b/Documentation/git-worktree.txt
@@ -67,7 +67,7 @@ doesn't exist, a new branch based on HEAD is automatically created as
 if `-b <branch>` was given.  If `<branch>` exists in the repository,
 it will be checked out in the new worktree, if it's not checked out
 anywhere else, otherwise the command will refuse to create the
-worktree.
+worktree (unless `--force` is used).
 
 list::
 
diff --git a/builtin/worktree.c b/builtin/worktree.c
index df5c0427ba..895838b943 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -28,7 +28,6 @@ struct add_opts {
 	int checkout;
 	int keep_locked;
 	const char *new_branch;
-	int force_new_branch;
 	int checkout_existing_branch;
 };
 
@@ -320,12 +319,12 @@ static int add_worktree(const char *path, const char *refname,
 		goto done;
 
 	if (opts->checkout_existing_branch)
-		fprintf(stderr, _("checking out branch '%s'"),
-			refname);
+		fprintf_ln(stderr, _("checking out branch '%s'"),
+			   refname);
 	else if (opts->new_branch)
-		fprintf(stderr, _("creating branch '%s'"), opts->new_branch);
+		fprintf_ln(stderr, _("creating branch '%s'"), opts->new_branch);
 
-	fprintf(stderr, _("worktree HEAD is now at %s"),
+	fprintf(stderr, _("new worktree HEAD is now at %s"),
 		find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
 
 	strbuf_reset(&sb);
@@ -434,8 +433,7 @@ static int add(int ac, const char **av, const char *prefix)
 	if (!strcmp(branch, "-"))
 		branch = "@{-1}";
 
-	opts.force_new_branch = !!new_branch_force;
-	if (opts.force_new_branch) {
+	if (new_branch_force) {
 		struct strbuf symref = STRBUF_INIT;
 
 		opts.new_branch = new_branch_force;
@@ -472,7 +470,7 @@ static int add(int ac, const char **av, const char *prefix)
 		struct child_process cp = CHILD_PROCESS_INIT;
 		cp.git_cmd = 1;
 		argv_array_push(&cp.args, "branch");
-		if (opts.force_new_branch)
+		if (new_branch_force)
 			argv_array_push(&cp.args, "--force");
 		argv_array_push(&cp.args, opts.new_branch);
 		argv_array_push(&cp.args, branch);
diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
index 721b0e4c26..fb99f4c46f 100755
--- a/t/t2025-worktree-add.sh
+++ b/t/t2025-worktree-add.sh
@@ -198,15 +198,15 @@ test_expect_success '"add" with <branch> omitted' '
 	test_cmp_rev HEAD bat
 '
 
-test_expect_success '"add" auto-vivify checks out existing branch' '
+test_expect_success '"add" checks out existing branch of dwimd name' '
 	test_commit c1 &&
 	test_commit c2 &&
-	git branch precious HEAD~1 &&
-	git worktree add precious &&
-	test_cmp_rev HEAD~1 precious &&
+	git branch dwim HEAD~1 &&
+	git worktree add dwim &&
+	test_cmp_rev HEAD~1 dwim &&
 	(
-		cd precious &&
-		test_cmp_rev precious HEAD
+		cd dwim &&
+		test_cmp_rev dwim HEAD
 	)
 '
 
@@ -216,6 +216,10 @@ test_expect_success '"add" auto-vivify fails with checked out branch' '
 	test_path_is_missing test-branch
 '
 
+test_expect_success '"add --force" with existing dwimd name doesnt die' '
+	git worktree add --force test-branch
+'
+
 test_expect_success '"add" no auto-vivify with --detach and <branch> omitted' '
 	git worktree add --detach mish/mash &&
 	test_must_fail git rev-parse mash -- &&

Thomas Gummerer (6):
  worktree: improve message when creating a new worktree
  worktree: be clearer when "add" dwim-ery kicks in
  worktree: remove force_new_branch from struct add_opts
  worktree: factor out dwim_branch function
  worktree: teach "add" to check out existing branches
  t2025: rename now outdated branch name

 Documentation/git-worktree.txt |  9 ++++--
 builtin/worktree.c             | 64 +++++++++++++++++++++++++++++++-----------
 t/t2025-worktree-add.sh        | 23 +++++++++++----
 3 files changed, 72 insertions(+), 24 deletions(-)

-- 
2.16.1.77.g8685934aa2
Thomas Gummerer· Mar 25, 2018, 13:49 UTC · re: Thomas Gummerer · lore

[PATCH v5 1/6] worktree: improve message when creating a new worktree

Currently 'git worktree add' produces output like the following, when '--no-checkout' is not given:

    Preparing foo (identifier foo)
    HEAD is now at 26da330922 <title>

where the first line is written to stderr, and the second line coming from 'git reset --hard' is written to stdout, even though both lines are supposed to tell the user what has happened. In addition to someone not familiar with 'git worktree', this might seem as if the current HEAD was modified, not the HEAD in the new working tree.

If the '--no-checkout' flag is given, the output of 'git worktree add' is just:

    Preparing foo (identifier foo)
even though the HEAD is set to a commit, which is just not checked out.

The identifier is also not particularly relevant for the user at the moment, as it's only used internally to distinguish between different worktrees that have the same $(basename <path>).

Fix these inconsistencies, and no longer show the identifier by making the 'git reset --hard' call quiet, and printing the message directly from the builtin command instead.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 builtin/worktree.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)
Show changes to builtin/worktree.c +10 −3
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 7cef5b120b..535734cc7f 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -303,8 +303,6 @@ static int add_worktree(const char *path, const char *refname,
 	strbuf_addf(&sb, "%s/commondir", sb_repo.buf);
 	write_file(sb.buf, "../..");
 
-	fprintf_ln(stderr, _("Preparing %s (identifier %s)"), path, name);
-
 	argv_array_pushf(&child_env, "%s=%s", GIT_DIR_ENVIRONMENT, sb_git.buf);
 	argv_array_pushf(&child_env, "%s=%s", GIT_WORK_TREE_ENVIRONMENT, path);
 	cp.git_cmd = 1;
@@ -320,10 +318,19 @@ static int add_worktree(const char *path, const char *refname,
 	if (ret)
 		goto done;
 
+	fprintf(stderr, _("new worktree HEAD is now at %s"),
+		find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
+
+	strbuf_reset(&sb);
+	pp_commit_easy(CMIT_FMT_ONELINE, commit, &sb);
+	if (sb.len > 0)
+		fprintf(stderr, " %s", sb.buf);
+	fputc('\n', stderr);
+
 	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", "--quiet", NULL);
 		cp.env = child_env.argv;
 		ret = run_command(&cp);
 		if (ret)

-- 
2.16.1.77.g8685934aa2
Thomas Gummerer· Mar 25, 2018, 13:49 UTC · re: Thomas Gummerer · lore

[PATCH v5 2/6] worktree: be clearer when "add" dwim-ery kicks in

Currently there is no indication in the "git worktree add" output that a new branch was created. This would be especially useful information in the case where the dwim of "git worktree add <path>" kicks in, as the user didn't explicitly ask for a new branch, but we create one from them.

Print some additional output showing that a branch was created and the branch name to help the user.

This will also be useful in the next commit, which introduces a new kind of dwim-ery of checking out the branch if it exists instead of refusing to create a new worktree in that case, and where it's nice to tell the user which kind of dwim-ery kicked in.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 builtin/worktree.c | 3 +++
 1 file changed, 3 insertions(+)
Show changes to builtin/worktree.c +3 −0
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 535734cc7f..a082230b6c 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -318,6 +318,9 @@ static int add_worktree(const char *path, const char *refname,
 	if (ret)
 		goto done;
 
+	if (opts->new_branch)
+		fprintf_ln(stderr, _("creating branch '%s'"), opts->new_branch);
+
 	fprintf(stderr, _("new worktree HEAD is now at %s"),
 		find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
 

-- 
2.16.1.77.g8685934aa2
Eric Sunshine· Mar 27, 2018, 08:59 UTC · re: Thomas Gummerer · lore

Re: [PATCH v5 2/6] worktree: be clearer when "add" dwim-ery kicks in

On Sun, Mar 25, 2018 at 9:49 AM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
Show 5 quoted lines
> Currently there is no indication in the "git worktree add" output that
> a new branch was created.  This would be especially useful information
> in the case where the dwim of "git worktree add <path>" kicks in, as the
> user didn't explicitly ask for a new branch, but we create one from
> them.
Failed to notice this last time around: s/from/for/
Perhaps Junio can tweak it when queuing.
> Print some additional output showing that a branch was created and the
> branch name to help the user.
>
> This will also be useful in the next commit, which introduces a new kind

It's no longer the _next_ commit which does this. Perhaps say instead "a subsequent commit". (Again, perhaps Junio can tweak it since it's not worth a re-roll.)

Show 10 quoted lines
> of dwim-ery of checking out the branch if it exists instead of refusing
> to create a new worktree in that case, and where it's nice to tell the
> user which kind of dwim-ery kicked in.
>
> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
> ---
> diff --git a/builtin/worktree.c b/builtin/worktree.c
> @@ -318,6 +318,9 @@ static int add_worktree(const char *path, const char *refname,
> +       if (opts->new_branch)
> +               fprintf_ln(stderr, _("creating branch '%s'"), opts->new_branch);

I didn't think of this before, but what happens with the original dwim-ery you added which checks out a remote branch matching the worktree name if no such local branch exists? I was wondering if we'd want to see a distinct and more informative message in that case, such as "creating branch '%s' from remote '%s'" or something. However, I see that we're already getting a message:

    Branch 'foo' set up to track remote branch 'foo' from 'origin'.
    creating branch 'foo'
    new worktree HEAD is now at d3adb33f boople

which is a bit weird since tracking appears to be set up before the branch itself is created. I thought that this was another UI regression of the sort I mentioned in [1], however, the messages were out of order even before the current patch series:

    Branch 'foo' set up to track remote branch 'foo' from 'origin'.
    Preparing foo (identifier foo)
    Checking out files: 100% (9999/9999), done.
    HEAD is now at d3adb33f boople

This highlights another regression introduced by this series. Patch 1/6 suppresses the "Checking out files:" message, which is a bit unfortunate for decent sized worktrees. I'm not sure I'm entirely happy about that loss. Thoughts?

[1]: https://public-inbox.org/git/CAPig+cT8i9L9kbhx=b0sG4_QYNdoEDPW-1xypM9xzBqPmqR__Q@mail.gmail.com/
>         fprintf(stderr, _("new worktree HEAD is now at %s"),
>                 find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
Thomas Gummerer· Mar 30, 2018, 13:53 UTC · re: Eric Sunshine · lore

Re: [PATCH v5 2/6] worktree: be clearer when "add" dwim-ery kicks in

On 03/27, Eric Sunshine wrote:
Show 19 quoted lines
> On Sun, Mar 25, 2018 at 9:49 AM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
> > Currently there is no indication in the "git worktree add" output that
> > a new branch was created.  This would be especially useful information
> > in the case where the dwim of "git worktree add <path>" kicks in, as the
> > user didn't explicitly ask for a new branch, but we create one from
> > them.
> 
> Failed to notice this last time around: s/from/for/
> 
> Perhaps Junio can tweak it when queuing.
> 
> > Print some additional output showing that a branch was created and the
> > branch name to help the user.
> >
> > This will also be useful in the next commit, which introduces a new kind
> 
> It's no longer the _next_ commit which does this. Perhaps say instead
> "a subsequent commit". (Again, perhaps Junio can tweak it since it's
> not worth a re-roll.)
Right, will fix.
Show 26 quoted lines
> > of dwim-ery of checking out the branch if it exists instead of refusing
> > to create a new worktree in that case, and where it's nice to tell the
> > user which kind of dwim-ery kicked in.
> >
> > Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
> > ---
> > diff --git a/builtin/worktree.c b/builtin/worktree.c
> > @@ -318,6 +318,9 @@ static int add_worktree(const char *path, const char *refname,
> > +       if (opts->new_branch)
> > +               fprintf_ln(stderr, _("creating branch '%s'"), opts->new_branch);
> 
> I didn't think of this before, but what happens with the original
> dwim-ery you added which checks out a remote branch matching the
> worktree name if no such local branch exists? I was wondering if we'd
> want to see a distinct and more informative message in that case, such
> as "creating branch '%s' from remote '%s'" or something. However, I
> see that we're already getting a message:
> 
>     Branch 'foo' set up to track remote branch 'foo' from 'origin'.
>     creating branch 'foo'
>     new worktree HEAD is now at d3adb33f boople
> 
> which is a bit weird since tracking appears to be set up before the
> branch itself is created. I thought that this was another UI
> regression of the sort I mentioned in [1], however, the messages were
> out of order even before the current patch series:

Yeah I agree this is a bit odd. I did think about this, and the main reason why I didn't change this by passing the '--quiet' flag to 'git branch' which we call in the 'add()' function is to keep the information about the remote tracking.

Looking at where this information actually comes from, there's multiple different ways we'd have to distinguish to print this information properly.

Now that I put some more thought into this, I think there are a couple of ways to solve this, the easiest and cleanest of which would probably be to run 'git branch' through 'pipe_command', save the output and print it after the "creating branch 'foo'" message.

Show 9 quoted lines
>     Branch 'foo' set up to track remote branch 'foo' from 'origin'.
>     Preparing foo (identifier foo)
>     Checking out files: 100% (9999/9999), done.
>     HEAD is now at d3adb33f boople
> 
> This highlights another regression introduced by this series. Patch
> 1/6 suppresses the "Checking out files:" message, which is a bit
> unfortunate for decent sized worktrees. I'm not sure I'm entirely
> happy about that loss. Thoughts?

Tbh I never really noticed the "Checking out files" output, because the repositories I used day to day are usually of a smaller size, where checking out the files takes less than a second, so I would never even notice this output.

But while I don't care about it, others may, so I think it would be better to preserve this output. Maybe the best way to do that would be to not use 'run_command' to run 'git reset --hard', but to instead replace that with the internal functions.

I haven't actually looked at how hard this would be, but I'm guessing this may be the best option to avoid this UI regression. I'll play with this some more and see what I can come up with, and send a re-roll hopefully in a few days.

Thanks for your review!
> [1]: https://public-inbox.org/git/CAPig+cT8i9L9kbhx=b0sG4_QYNdoEDPW-1xypM9xzBqPmqR__Q@mail.gmail.com/
> 
> >         fprintf(stderr, _("new worktree HEAD is now at %s"),
> >                 find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
Thomas Gummerer· Mar 25, 2018, 13:49 UTC · re: Thomas Gummerer · lore

[PATCH v5 3/6] worktree: remove force_new_branch from struct add_opts

The 'force_new_branch' flag in 'struct add_opts' is only used inside the add function, where we already have the same information stored in the 'new_branch_force' variable. Avoid that unnecessary duplication.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 builtin/worktree.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)
Show changes to builtin/worktree.c +2 −4
diff --git a/builtin/worktree.c b/builtin/worktree.c
index a082230b6c..1e4a919a00 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -28,7 +28,6 @@ struct add_opts {
 	int checkout;
 	int keep_locked;
 	const char *new_branch;
-	int force_new_branch;
 };
 
 static int show_only;
@@ -405,8 +404,7 @@ static int add(int ac, const char **av, const char *prefix)
 	if (!strcmp(branch, "-"))
 		branch = "@{-1}";
 
-	opts.force_new_branch = !!new_branch_force;
-	if (opts.force_new_branch) {
+	if (new_branch_force) {
 		struct strbuf symref = STRBUF_INIT;
 
 		opts.new_branch = new_branch_force;
@@ -450,7 +448,7 @@ static int add(int ac, const char **av, const char *prefix)
 		struct child_process cp = CHILD_PROCESS_INIT;
 		cp.git_cmd = 1;
 		argv_array_push(&cp.args, "branch");
-		if (opts.force_new_branch)
+		if (new_branch_force)
 			argv_array_push(&cp.args, "--force");
 		argv_array_push(&cp.args, opts.new_branch);
 		argv_array_push(&cp.args, branch);

-- 
2.16.1.77.g8685934aa2
Eric Sunshine· Mar 27, 2018, 09:00 UTC · re: Thomas Gummerer · lore

Re: [PATCH v5 3/6] worktree: remove force_new_branch from struct add_opts

On Sun, Mar 25, 2018 at 9:49 AM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
> The 'force_new_branch' flag in 'struct add_opts' is only used inside the
> add function, where we already have the same information stored in the
> 'new_branch_force' variable.  Avoid that unnecessary duplication.

When I was reviewing your original dwim-ery series (inferring 'foo' from 'origin/foo'), I noticed that 'struct add_opts' had accumulated a number of unnecessary members over time, including this one. My plan was to submit a patch removing all those pointless members after your dwim-ery series settled, however, I never got around to it.

This patch might be a good opportunity for doing that cleanup wholesale, removing all unneeded members rather than just the one. (If so, you'd probably want to move to this patch to the front of the series as cleanup before the meatier changes.) Anyhow, it's just a thought; feel free to respond with "it's outside the scope of this series" if you're not interested in doing it.

> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Thomas Gummerer· Mar 30, 2018, 13:55 UTC · re: Eric Sunshine · lore

Re: [PATCH v5 3/6] worktree: remove force_new_branch from struct add_opts

On 03/27, Eric Sunshine wrote:
Show 10 quoted lines
> On Sun, Mar 25, 2018 at 9:49 AM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
> > The 'force_new_branch' flag in 'struct add_opts' is only used inside the
> > add function, where we already have the same information stored in the
> > 'new_branch_force' variable.  Avoid that unnecessary duplication.
> 
> When I was reviewing your original dwim-ery series (inferring 'foo'
> from 'origin/foo'), I noticed that 'struct add_opts' had accumulated a
> number of unnecessary members over time, including this one. My plan
> was to submit a patch removing all those pointless members after your
> dwim-ery series settled, however, I never got around to it.

Ah right, I didn't look at them in detail, so I failed to notice that. While I'm already in the area I may as well do that, thanks for the suggestion!

Show 8 quoted lines
> This patch might be a good opportunity for doing that cleanup
> wholesale, removing all unneeded members rather than just the one. (If
> so, you'd probably want to move to this patch to the front of the
> series as cleanup before the meatier changes.) Anyhow, it's just a
> thought; feel free to respond with "it's outside the scope of this
> series" if you're not interested in doing it.
> 
> > Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Thomas Gummerer· Mar 25, 2018, 13:49 UTC · re: Thomas Gummerer · lore

[PATCH v5 4/6] worktree: factor out dwim_branch function

Factor out a dwim_branch function, which takes care of the dwim'ery in 'git worktree add <path>'. It's not too much code currently, but we're adding a new kind of dwim in a subsequent patch, at which point it makes more sense to have it as a separate function.

Factor it out now to reduce the patch noise in the next patch.
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 builtin/worktree.c | 27 +++++++++++++++++----------
 1 file changed, 17 insertions(+), 10 deletions(-)
Show changes to builtin/worktree.c +17 −10
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 1e4a919a00..c296c3eacb 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -366,6 +366,20 @@ static int add_worktree(const char *path, const char *refname,
 	return ret;
 }
 
+static const char *dwim_branch(const char *path, struct add_opts *opts)
+{
+	int n;
+	const char *s = worktree_basename(path, &n);
+	opts->new_branch = xstrndup(s, n);
+	if (guess_remote) {
+		struct object_id oid;
+		const char *remote =
+			unique_tracking_name(opts->new_branch, &oid);
+		return remote;
+	}
+	return NULL;
+}
+
 static int add(int ac, const char **av, const char *prefix)
 {
 	struct add_opts opts;
@@ -417,16 +431,9 @@ static int add(int ac, const char **av, const char *prefix)
 	}
 
 	if (ac < 2 && !opts.new_branch && !opts.detach) {
-		int n;
-		const char *s = worktree_basename(path, &n);
-		opts.new_branch = xstrndup(s, n);
-		if (guess_remote) {
-			struct object_id oid;
-			const char *remote =
-				unique_tracking_name(opts.new_branch, &oid);
-			if (remote)
-				branch = remote;
-		}
+		const char *dwim_branchname = dwim_branch(path, &opts);
+		if (dwim_branchname)
+			branch = dwim_branchname;
 	}
 
 	if (ac == 2 && !opts.new_branch && !opts.detach) {

-- 
2.16.1.77.g8685934aa2
Eric Sunshine· Mar 27, 2018, 09:01 UTC · re: Thomas Gummerer · lore

Re: [PATCH v5 4/6] worktree: factor out dwim_branch function

On Sun, Mar 25, 2018 at 9:49 AM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
Show 23 quoted lines
> Factor out a dwim_branch function, which takes care of the dwim'ery in
> 'git worktree add <path>'.  It's not too much code currently, but we're
> adding a new kind of dwim in a subsequent patch, at which point it makes
> more sense to have it as a separate function.
> [...]
> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
> ---
> diff --git a/builtin/worktree.c b/builtin/worktree.c
> @@ -417,16 +431,9 @@ static int add(int ac, const char **av, const char *prefix)
>         if (ac < 2 && !opts.new_branch && !opts.detach) {
> -               int n;
> -               const char *s = worktree_basename(path, &n);
> -               opts.new_branch = xstrndup(s, n);
> -               if (guess_remote) {
> -                       struct object_id oid;
> -                       const char *remote =
> -                               unique_tracking_name(opts.new_branch, &oid);
> -                       if (remote)
> -                               branch = remote;
> -               }
> +               const char *dwim_branchname = dwim_branch(path, &opts);
> +               if (dwim_branchname)
> +                       branch = dwim_branchname;

I don't care strongly but the name 'dwim_branchname' is awfully long in a context where it's assigned the result of a call to dwim_branch(). In this tiny code block, a short and sweet name 's' would be easy to grok; there'd be no confusion.

Anyhow, it's subjective and not at all worth a re-roll.
Thomas Gummerer· Mar 25, 2018, 13:49 UTC · re: Thomas Gummerer · lore

[PATCH v5 5/6] worktree: teach "add" to check out existing branches

Currently 'git worktree add <path>' creates a new branch named after the basename of the path by default. If a branch with that name already exists, the command refuses to do anything, unless the '--force' option is given.

However we can do a little better than that, and check the branch out if it is not checked out anywhere else. This will help users who just want to check an existing branch out into a new worktree, and save a few keystrokes.

As the current behaviour is to simply 'die()' when a branch with the name of the basename of the path already exists, there are no backwards compatibility worries here.

We will still 'die()' if the branch is checked out in another worktree, unless the --force flag is passed.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 Documentation/git-worktree.txt |  9 +++++++--
 builtin/worktree.c             | 19 +++++++++++++++++--
 t/t2025-worktree-add.sh        | 19 ++++++++++++++++---
 3 files changed, 40 insertions(+), 7 deletions(-)
Show changes to 3 files +40 −7

Documentation/git-worktree.txt, builtin/worktree.c, t/t2025-worktree-add.sh

diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index 41585f535d..eaa6bf713f 100644
--- a/Documentation/git-worktree.txt
+++ b/Documentation/git-worktree.txt
@@ -61,8 +61,13 @@ $ git worktree add --track -b <branch> <path> <remote>/<branch>
 ------------
 +
 If `<commit-ish>` is omitted and neither `-b` nor `-B` nor `--detach` used,
-then, as a convenience, a new branch based at HEAD is created automatically,
-as if `-b $(basename <path>)` was specified.
+then, as a convenience, a worktree with a branch named after
+`$(basename <path>)` (call it `<branch>`) is created.  If `<branch>`
+doesn't exist, a new branch based on HEAD is automatically created as
+if `-b <branch>` was given.  If `<branch>` exists in the repository,
+it will be checked out in the new worktree, if it's not checked out
+anywhere else, otherwise the command will refuse to create the
+worktree (unless `--force` is used).
 
 list::
 
diff --git a/builtin/worktree.c b/builtin/worktree.c
index c296c3eacb..895838b943 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -28,6 +28,7 @@ struct add_opts {
 	int checkout;
 	int keep_locked;
 	const char *new_branch;
+	int checkout_existing_branch;
 };
 
 static int show_only;
@@ -317,7 +318,10 @@ static int add_worktree(const char *path, const char *refname,
 	if (ret)
 		goto done;
 
-	if (opts->new_branch)
+	if (opts->checkout_existing_branch)
+		fprintf_ln(stderr, _("checking out branch '%s'"),
+			   refname);
+	else if (opts->new_branch)
 		fprintf_ln(stderr, _("creating branch '%s'"), opts->new_branch);
 
 	fprintf(stderr, _("new worktree HEAD is now at %s"),
@@ -370,7 +374,18 @@ static const char *dwim_branch(const char *path, struct add_opts *opts)
 {
 	int n;
 	const char *s = worktree_basename(path, &n);
-	opts->new_branch = xstrndup(s, n);
+	const char *branchname = xstrndup(s, n);
+	struct strbuf ref = STRBUF_INIT;
+
+	if (!strbuf_check_branch_ref(&ref, branchname) &&
+	    ref_exists(ref.buf)) {
+		opts->checkout_existing_branch = 1;
+		strbuf_release(&ref);
+		UNLEAK(branchname);
+		return branchname;
+	}
+
+	opts->new_branch = branchname;
 	if (guess_remote) {
 		struct object_id oid;
 		const char *remote =
diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
index 2b95944973..ae602cf20e 100755
--- a/t/t2025-worktree-add.sh
+++ b/t/t2025-worktree-add.sh
@@ -198,13 +198,26 @@ test_expect_success '"add" with <branch> omitted' '
 	test_cmp_rev HEAD bat
 '
 
-test_expect_success '"add" auto-vivify does not clobber existing branch' '
+test_expect_success '"add" checks out existing branch of dwimd name' '
 	test_commit c1 &&
 	test_commit c2 &&
 	git branch precious HEAD~1 &&
-	test_must_fail git worktree add precious &&
+	git worktree add precious &&
 	test_cmp_rev HEAD~1 precious &&
-	test_path_is_missing precious
+	(
+		cd precious &&
+		test_cmp_rev precious HEAD
+	)
+'
+
+test_expect_success '"add" auto-vivify fails with checked out branch' '
+	git checkout -b test-branch &&
+	test_must_fail git worktree add test-branch &&
+	test_path_is_missing test-branch
+'
+
+test_expect_success '"add --force" with existing dwimd name doesnt die' '
+	git worktree add --force test-branch
 '
 
 test_expect_success '"add" no auto-vivify with --detach and <branch> omitted' '

-- 
2.16.1.77.g8685934aa2
Eric Sunshine· Mar 27, 2018, 09:04 UTC · re: Thomas Gummerer · lore

Re: [PATCH v5 5/6] worktree: teach "add" to check out existing branches

On Sun, Mar 25, 2018 at 9:49 AM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
Show 18 quoted lines
> Currently 'git worktree add <path>' creates a new branch named after the
> basename of the path by default.  If a branch with that name already
> exists, the command refuses to do anything, unless the '--force' option
> is given.
>
> However we can do a little better than that, and check the branch out if
> it is not checked out anywhere else.  This will help users who just want
> to check an existing branch out into a new worktree, and save a few
> keystrokes.
> [...]
> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
> ---
> diff --git a/builtin/worktree.c b/builtin/worktree.c
> @@ -317,7 +318,10 @@ static int add_worktree(const char *path, const char *refname,
> -       if (opts->new_branch)
> +       if (opts->checkout_existing_branch)
> +               fprintf_ln(stderr, _("checking out branch '%s'"),
> +                          refname);

This fprintf_ln() can easily fit on one line; no need to wrap 'refname' to the next one.

Not worth a re-roll, though.
Show 18 quoted lines
> +       else if (opts->new_branch)
>                 fprintf_ln(stderr, _("creating branch '%s'"), opts->new_branch);
> diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
> @@ -198,13 +198,26 @@ test_expect_success '"add" with <branch> omitted' '
> -test_expect_success '"add" auto-vivify does not clobber existing branch' '
> +test_expect_success '"add" checks out existing branch of dwimd name' '
>         test_commit c1 &&
>         test_commit c2 &&
>         git branch precious HEAD~1 &&
> -       test_must_fail git worktree add precious &&
> +       git worktree add precious &&
>         test_cmp_rev HEAD~1 precious &&
> -       test_path_is_missing precious
> +       (
> +               cd precious &&
> +               test_cmp_rev precious HEAD
> +       )
> +'

Looking at this more closely, once it stops being a "don't clobber precious branch" test, it's doing more than it needs to do, thus is confusing for future readers. The setup -- creating two commits and making "precious" point one commit back -- was very intentional and allowed the test to verify not only that the worktree wasn't created but that "precious" didn't change to reference a different commit. However, _none_ of this matters once it becomes a dwim'ing test; the unnecessary code is confusing since it doesn't make sense in the context of dwim'ing. I _think_ the entire test can collapse to:

    git branch existing &&
    git worktree add existing &&
    (
        cd existing &&
        test_cmp_rev existing HEAD
    )

In other words, this patch should drop the "precious" test altogether and just introduce a new dwim'ing test (and drop patch 6/6).

I do think that with the potential confusion to future readers, this does deserve a re-roll.

Show 9 quoted lines
> +test_expect_success '"add" auto-vivify fails with checked out branch' '
> +       git checkout -b test-branch &&
> +       test_must_fail git worktree add test-branch &&
> +       test_path_is_missing test-branch
> +'
> +
> +test_expect_success '"add --force" with existing dwimd name doesnt die' '
> +       git worktree add --force test-branch
>  '
Thomas Gummerer· Mar 30, 2018, 14:04 UTC · re: Eric Sunshine · lore

Re: [PATCH v5 5/6] worktree: teach "add" to check out existing branches

On 03/27, Eric Sunshine wrote:
Show 66 quoted lines
> On Sun, Mar 25, 2018 at 9:49 AM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
> > Currently 'git worktree add <path>' creates a new branch named after the
> > basename of the path by default.  If a branch with that name already
> > exists, the command refuses to do anything, unless the '--force' option
> > is given.
> >
> > However we can do a little better than that, and check the branch out if
> > it is not checked out anywhere else.  This will help users who just want
> > to check an existing branch out into a new worktree, and save a few
> > keystrokes.
> > [...]
> > Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
> > ---
> > diff --git a/builtin/worktree.c b/builtin/worktree.c
> > @@ -317,7 +318,10 @@ static int add_worktree(const char *path, const char *refname,
> > -       if (opts->new_branch)
> > +       if (opts->checkout_existing_branch)
> > +               fprintf_ln(stderr, _("checking out branch '%s'"),
> > +                          refname);
> 
> This fprintf_ln() can easily fit on one line; no need to wrap
> 'refname' to the next one.
> 
> Not worth a re-roll, though.
> 
> > +       else if (opts->new_branch)
> >                 fprintf_ln(stderr, _("creating branch '%s'"), opts->new_branch);
> > diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
> > @@ -198,13 +198,26 @@ test_expect_success '"add" with <branch> omitted' '
> > -test_expect_success '"add" auto-vivify does not clobber existing branch' '
> > +test_expect_success '"add" checks out existing branch of dwimd name' '
> >         test_commit c1 &&
> >         test_commit c2 &&
> >         git branch precious HEAD~1 &&
> > -       test_must_fail git worktree add precious &&
> > +       git worktree add precious &&
> >         test_cmp_rev HEAD~1 precious &&
> > -       test_path_is_missing precious
> > +       (
> > +               cd precious &&
> > +               test_cmp_rev precious HEAD
> > +       )
> > +'
> 
> Looking at this more closely, once it stops being a "don't clobber
> precious branch" test, it's doing more than it needs to do, thus is
> confusing for future readers. The setup -- creating two commits and
> making "precious" point one commit back -- was very intentional and
> allowed the test to verify not only that the worktree wasn't created
> but that "precious" didn't change to reference a different commit.
> However, _none_ of this matters once it becomes a dwim'ing test; the
> unnecessary code is confusing since it doesn't make sense in the
> context of dwim'ing. I _think_ the entire test can collapse to:
> 
>     git branch existing &&
>     git worktree add existing &&
>     (
>         cd existing &&
>         test_cmp_rev existing HEAD
>     )
> 
> In other words, this patch should drop the "precious" test altogether
> and just introduce a new dwim'ing test (and drop patch 6/6).
> 
> I do think that with the potential confusion to future readers, this
> does deserve a re-roll.

Hmm I do think that it's important to have the branch we create the new working tree from different from the branch of the main working tree, to make sure we don't accidentally overwrite an existing branch, and to show that the new branch is checked out.

Maybe I'm overly paranoid though?
Show 9 quoted lines
> > +test_expect_success '"add" auto-vivify fails with checked out branch' '
> > +       git checkout -b test-branch &&
> > +       test_must_fail git worktree add test-branch &&
> > +       test_path_is_missing test-branch
> > +'
> > +
> > +test_expect_success '"add --force" with existing dwimd name doesnt die' '
> > +       git worktree add --force test-branch
> >  '
Thomas Gummerer· Mar 25, 2018, 13:49 UTC · re: Thomas Gummerer · lore

[PATCH v5 6/6] t2025: rename now outdated branch name

Before the previous commit, the branch named precious was used to check that 'git worktree' wouldn't clobber the branch. While 'git worktree' still shouldn't (and doesn't) modify the branch, that's no longer the main thing the test is checking.

Rename the branch to avoid making future readers wonder why this particular branch is more "precious" than others.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 t/t2025-worktree-add.sh | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)
Show changes to t/t2025-worktree-add.sh +5 −5
diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
index ae602cf20e..fb99f4c46f 100755
--- a/t/t2025-worktree-add.sh
+++ b/t/t2025-worktree-add.sh
@@ -201,12 +201,12 @@ test_expect_success '"add" with <branch> omitted' '
 test_expect_success '"add" checks out existing branch of dwimd name' '
 	test_commit c1 &&
 	test_commit c2 &&
-	git branch precious HEAD~1 &&
-	git worktree add precious &&
-	test_cmp_rev HEAD~1 precious &&
+	git branch dwim HEAD~1 &&
+	git worktree add dwim &&
+	test_cmp_rev HEAD~1 dwim &&
 	(
-		cd precious &&
-		test_cmp_rev precious HEAD
+		cd dwim &&
+		test_cmp_rev dwim HEAD
 	)
 '
 

-- 
2.16.1.77.g8685934aa2
Eric Sunshine· Mar 27, 2018, 08:58 UTC · re: Thomas Gummerer · lore

Re: [PATCH v5 0/6] worktree: teach "add" to check out existing branches

On Sun, Mar 25, 2018 at 9:49 AM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
> Thanks Eric for the review of the previous round and Duy and Junio for
> additional comments.
> This round should address all of Eric's comments from the previous round.

Thanks, it appears to cover my review comments from the previous round. I do have some additional comments on this round (which I could have raised with the previous round if I had thought of them at the time).

> As explained in more detail in a reply to the review comment directly,
> I did not add an enum to 'struct add_opts', for 'force_new_branch' and
> 'checkout_existing_branch', but instead removed 'force_new_branch'
> from the struct as it's not required.

Makes sense. In fact, I had thoughts along these lines during your previous dwim-ery series. See my comments on patch 3/6.

> The rest of the updates are mainly in the user facing messages,
> documentation and one added test.
> Interdiff below:

The interdiff looks sane. Unfortunately, due to UI regressions, I'm having second thoughts about whether this series is going in the right direction. See my comments on patch 2/6.

Thomas Gummerer· Mar 30, 2018, 14:08 UTC · re: Eric Sunshine · lore

Re: [PATCH v5 0/6] worktree: teach "add" to check out existing branches

On 03/27, Eric Sunshine wrote:
Show 25 quoted lines
> On Sun, Mar 25, 2018 at 9:49 AM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
> > Thanks Eric for the review of the previous round and Duy and Junio for
> > additional comments.
> > This round should address all of Eric's comments from the previous round.
> 
> Thanks, it appears to cover my review comments from the previous
> round. I do have some additional comments on this round (which I could
> have raised with the previous round if I had thought of them at the
> time).
> 
> > As explained in more detail in a reply to the review comment directly,
> > I did not add an enum to 'struct add_opts', for 'force_new_branch' and
> > 'checkout_existing_branch', but instead removed 'force_new_branch'
> > from the struct as it's not required.
> 
> Makes sense. In fact, I had thoughts along these lines during your
> previous dwim-ery series. See my comments on patch 3/6.
> 
> > The rest of the updates are mainly in the user facing messages,
> > documentation and one added test.
> > Interdiff below:
> 
> The interdiff looks sane. Unfortunately, due to UI regressions, I'm
> having second thoughts about whether this series is going in the right
> direction. See my comments on patch 2/6.

Thanks for your reviews of this series! As I mentioned in the reply there I'm going to see whether or not I can fix those regressions (hopefully I can :)), and send a re-roll.

Thomas Gummerer· Mar 31, 2018, 15:17 UTC · re: Thomas Gummerer · lore

[PATCH v6 0/6] worktree: teach "add" to check out existing branches

Thanks Eric for the review of the last round.

Previous rounds are at <20180121120208.12760-1-t.gummerer@gmail.com>, <20180204221305.28300-1-t.gummerer@gmail.com>, <20180317220830.30963-1-t.gummerer@gmail.com>, <20180317222219.4940-1-t.gummerer@gmail.com> and 20180325134947.25828-1-t.gummerer@gmail.com.

This round should fix all the UI issues Eric found in the last round.
The changes I made in a bit more detail:
- in addition to removing the 'force_new_branch' flag from 'struct
  add_opts', also remove the 'new_branch' member, which is local to
  the 'add()' function.  The other four members are needed in the
  'worktree_add()' function, so I left them there.   This patch is now
  the first patch in the series.
- added a new commit introducing a new hidden --show-new-head-line
  flag in 'git reset'.  This is used to suppress the "HEAD is now at
  ..."  line that 'git reset --hard' usually prints, so we can replace
  it with our own "New worktree HEAD is now at ..." line instead,
  while keeping the progress indicator for larger repositories.
  I guess this may be the most controversial bit at this point, as
  we'd be adding an option for internal use only.  Not sure how we
  feel about that. But short of going back to the old output format, I
  don't see a good option to make this work otherwise.  I tried
  re-using internal functions for this, but until we have 'struct
  repository' everywhere, that's going to be quite hard.
- Print the "Creating branch ..." and "Checking out branch ..."
  messages earlier in the process.  This is mainly to avoid the out of
  order "Branch '...' now set up to track ..." message.
- Various commit message and style cleanups

Note that these fixes are quite differently executed than I had imagined them in the reply to the review comments, as things didn't work as I had imagined. The UI problems should be fixed now nonetheless :)

Some examples of the new UI behaviour here for reference:
 - guess-remote mode
    $ git worktree add --guess-remote ../next
    Creating branch 'next'
    Branch 'next' set up to track remote branch 'next' from 'origin'.
    New worktree HEAD is now at caa68db14 Merge branch 'sb/packfiles-in-repository' into next
 - original dwim (create a branch based on the current HEAD)
    $ git worktree add ../test
    Creating branch 'test'
    New worktree HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
 - new dwim (check out existing branch)
    $ git worktree add ../test
    Checking out branch 'test'
    New worktree HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
 - no new branch created
 
    $ git worktree add ../test2 origin/master
    New worktree HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
 - large repository (with original dwim)
    $ g worktree add ../test
    Creating branch 'test'
    Checking out files: 100% (62915/62915), done.
    New worktree HEAD is now at c2a9838452a4 Merge tag 'for-4.16/dm-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm

Compare this to the old UI (new dwim omitted, as there's no old version of that):

 - guess-remote mode
    $ git worktree add --guess-remote ../next
    Branch 'next' set up to track remote branch 'next' from 'origin'.
    Preparing ../next (identifier next)
    HEAD is now at caa68db14 Merge branch 'sb/packfiles-in-repository' into next
 - original dwim (create a branch based on the current HEAD)
    $ git worktree add ../test
    Preparing ../test (identifier test)
    HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
 - no new branch created
    $ git worktree add ../test2 origin/master
    Preparing ../test2 (identifier test2)
    HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
 - large repository
    $ git worktree add ../test
    Preparing ../test (identifier test)
    Checking out files: 100% (62915/62915), done.
    HEAD is now at c2a9838452a4 Merge tag 'for-4.16/dm-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm

The one thing we are loosing is a context line before "Checking out files:", if no new branch is created. Personally I feel like that's acceptable, as the user just used the 'git worktree add' command, so it should be intuitive where those files are being checked out.

We could also print "Preparing worktree <path>" as a line in the beginning (without mentioning the identifier, so we can print it in the 'add()' function), but I don't feel like that's worth spending the extra screen estate. I don't feel strongly about that though, so if someone has a moderately strong preference for that line being there, I'm happy to add it.

Interdiff below:
Show changes to 4 files +46 −39

builtin/reset.c, builtin/worktree.c, t/t2025-worktree-add.sh, t/t7102-reset.sh

diff --git a/builtin/reset.c b/builtin/reset.c
index e15f595799..54b2576449 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -288,6 +288,7 @@ static int git_reset_config(const char *var, const char *value, void *cb)
 int cmd_reset(int argc, const char **argv, const char *prefix)
 {
 	int reset_type = NONE, update_ref_status = 0, quiet = 0;
+	int show_new_head_line = 1;
 	int patch_mode = 0, unborn;
 	const char *rev;
 	struct object_id oid;
@@ -310,6 +311,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
 		OPT_BOOL('p', "patch", &patch_mode, N_("select hunks interactively")),
 		OPT_BOOL('N', "intent-to-add", &intent_to_add,
 				N_("record only the fact that removed paths will be added later")),
+		OPT_HIDDEN_BOOL(0, "show-new-head-line", &show_new_head_line, N_("show information on the new HEAD")),
 		OPT_END()
 	};
 
@@ -403,7 +405,8 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
 		 * switched to, saving the previous head in ORIG_HEAD before. */
 		update_ref_status = reset_refs(rev, &oid);
 
-		if (reset_type == HARD && !update_ref_status && !quiet)
+		if (reset_type == HARD && !update_ref_status && !quiet &&
+		    show_new_head_line)
 			print_new_head_line(lookup_commit_reference(&oid));
 	}
 	if (!pathspec.nr)
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 895838b943..511d0aa370 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -27,8 +27,6 @@ struct add_opts {
 	int detach;
 	int checkout;
 	int keep_locked;
-	const char *new_branch;
-	int checkout_existing_branch;
 };
 
 static int show_only;
@@ -318,31 +316,26 @@ static int add_worktree(const char *path, const char *refname,
 	if (ret)
 		goto done;
 
-	if (opts->checkout_existing_branch)
-		fprintf_ln(stderr, _("checking out branch '%s'"),
-			   refname);
-	else if (opts->new_branch)
-		fprintf_ln(stderr, _("creating branch '%s'"), opts->new_branch);
-
-	fprintf(stderr, _("new worktree HEAD is now at %s"),
-		find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
-
-	strbuf_reset(&sb);
-	pp_commit_easy(CMIT_FMT_ONELINE, commit, &sb);
-	if (sb.len > 0)
-		fprintf(stderr, " %s", sb.buf);
-	fputc('\n', stderr);
-
 	if (opts->checkout) {
 		cp.argv = NULL;
 		argv_array_clear(&cp.args);
-		argv_array_pushl(&cp.args, "reset", "--hard", "--quiet", NULL);
+		argv_array_pushl(&cp.args, "reset", "--hard", NULL);
+		argv_array_push(&cp.args, "--no-show-new-head-line");
 		cp.env = child_env.argv;
 		ret = run_command(&cp);
 		if (ret)
 			goto done;
 	}
 
+	fprintf(stderr, _("New worktree HEAD is now at %s"),
+		find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
+
+	strbuf_reset(&sb);
+	pp_commit_easy(CMIT_FMT_ONELINE, commit, &sb);
+	if (sb.len > 0)
+		fprintf(stderr, " %s", sb.buf);
+	fputc('\n', stderr);
+
 	is_junk = 0;
 	FREE_AND_NULL(junk_work_tree);
 	FREE_AND_NULL(junk_git_dir);
@@ -370,7 +363,8 @@ static int add_worktree(const char *path, const char *refname,
 	return ret;
 }
 
-static const char *dwim_branch(const char *path, struct add_opts *opts)
+static const char *dwim_branch(const char *path, const char **new_branch,
+			       int *checkout_existing_branch)
 {
 	int n;
 	const char *s = worktree_basename(path, &n);
@@ -379,17 +373,17 @@ static const char *dwim_branch(const char *path, struct add_opts *opts)
 
 	if (!strbuf_check_branch_ref(&ref, branchname) &&
 	    ref_exists(ref.buf)) {
-		opts->checkout_existing_branch = 1;
+		*checkout_existing_branch = 1;
 		strbuf_release(&ref);
 		UNLEAK(branchname);
 		return branchname;
 	}
 
-	opts->new_branch = branchname;
+	*new_branch = branchname;
 	if (guess_remote) {
 		struct object_id oid;
 		const char *remote =
-			unique_tracking_name(opts->new_branch, &oid);
+			unique_tracking_name(*new_branch, &oid);
 		return remote;
 	}
 	return NULL;
@@ -401,10 +395,12 @@ static int add(int ac, const char **av, const char *prefix)
 	const char *new_branch_force = NULL;
 	char *path;
 	const char *branch;
+	const char *new_branch = NULL;
 	const char *opt_track = NULL;
+	int checkout_existing_branch = 0;
 	struct option options[] = {
 		OPT__FORCE(&opts.force, N_("checkout <branch> even if already checked out in other worktree")),
-		OPT_STRING('b', NULL, &opts.new_branch, N_("branch"),
+		OPT_STRING('b', NULL, &new_branch, N_("branch"),
 			   N_("create a new branch")),
 		OPT_STRING('B', NULL, &new_branch_force, N_("branch"),
 			   N_("create or reset a branch")),
@@ -422,7 +418,7 @@ static int add(int ac, const char **av, const char *prefix)
 	memset(&opts, 0, sizeof(opts));
 	opts.checkout = 1;
 	ac = parse_options(ac, av, prefix, options, worktree_usage, 0);
-	if (!!opts.detach + !!opts.new_branch + !!new_branch_force > 1)
+	if (!!opts.detach + !!new_branch + !!new_branch_force > 1)
 		die(_("-b, -B, and --detach are mutually exclusive"));
 	if (ac < 1 || ac > 2)
 		usage_with_options(worktree_usage, options);
@@ -436,22 +432,23 @@ static int add(int ac, const char **av, const char *prefix)
 	if (new_branch_force) {
 		struct strbuf symref = STRBUF_INIT;
 
-		opts.new_branch = new_branch_force;
+		new_branch = new_branch_force;
 
 		if (!opts.force &&
-		    !strbuf_check_branch_ref(&symref, opts.new_branch) &&
+		    !strbuf_check_branch_ref(&symref, new_branch) &&
 		    ref_exists(symref.buf))
 			die_if_checked_out(symref.buf, 0);
 		strbuf_release(&symref);
 	}
 
-	if (ac < 2 && !opts.new_branch && !opts.detach) {
-		const char *dwim_branchname = dwim_branch(path, &opts);
-		if (dwim_branchname)
-			branch = dwim_branchname;
+	if (ac < 2 && !new_branch && !opts.detach) {
+		const char *s = dwim_branch(path, &new_branch,
+					    &checkout_existing_branch);
+		if (s)
+			branch = s;
 	}
 
-	if (ac == 2 && !opts.new_branch && !opts.detach) {
+	if (ac == 2 && !new_branch && !opts.detach) {
 		struct object_id oid;
 		struct commit *commit;
 		const char *remote;
@@ -460,25 +457,29 @@ static int add(int ac, const char **av, const char *prefix)
 		if (!commit) {
 			remote = unique_tracking_name(branch, &oid);
 			if (remote) {
-				opts.new_branch = branch;
+				new_branch = branch;
 				branch = remote;
 			}
 		}
 	}
 
-	if (opts.new_branch) {
+	if (new_branch) {
 		struct child_process cp = CHILD_PROCESS_INIT;
+
+		fprintf_ln(stderr, _("Creating branch '%s'"), new_branch);
 		cp.git_cmd = 1;
 		argv_array_push(&cp.args, "branch");
 		if (new_branch_force)
 			argv_array_push(&cp.args, "--force");
-		argv_array_push(&cp.args, opts.new_branch);
+		argv_array_push(&cp.args, new_branch);
 		argv_array_push(&cp.args, branch);
 		if (opt_track)
 			argv_array_push(&cp.args, opt_track);
 		if (run_command(&cp))
 			return -1;
-		branch = opts.new_branch;
+		branch = new_branch;
+	} else if (checkout_existing_branch) {
+		  fprintf_ln(stderr, _("Checking out branch '%s'"), branch);
 	} else if (opt_track) {
 		die(_("--[no-]track can only be used if a new branch is created"));
 	}
diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
index fb99f4c46f..f72cb0eb0b 100755
--- a/t/t2025-worktree-add.sh
+++ b/t/t2025-worktree-add.sh
@@ -199,8 +199,6 @@ test_expect_success '"add" with <branch> omitted' '
 '
 
 test_expect_success '"add" checks out existing branch of dwimd name' '
-	test_commit c1 &&
-	test_commit c2 &&
 	git branch dwim HEAD~1 &&
 	git worktree add dwim &&
 	test_cmp_rev HEAD~1 dwim &&
@@ -210,7 +208,7 @@ test_expect_success '"add" checks out existing branch of dwimd name' '
 	)
 '
 
-test_expect_success '"add" auto-vivify fails with checked out branch' '
+test_expect_success '"add <path>" dwim fails with checked out branch' '
 	git checkout -b test-branch &&
 	test_must_fail git worktree add test-branch &&
 	test_path_is_missing test-branch
diff --git a/t/t7102-reset.sh b/t/t7102-reset.sh
index 95653a08ca..a160f78aba 100755
--- a/t/t7102-reset.sh
+++ b/t/t7102-reset.sh
@@ -568,4 +568,9 @@ test_expect_success 'reset --mixed sets up work tree' '
 	test_cmp expect actual
 '
 
+test_expect_success 'reset --no-show-new-head-line suppresses "HEAD is now at" output' '
+	git reset --hard --no-show-new-head-line HEAD >actual &&
+	! grep "HEAD is now at" <actual
+'
+
 test_done

Thomas Gummerer (6):
  worktree: remove extra members from struct add_opts
  reset: introduce show-new-head-line option
  worktree: improve message when creating a new worktree
  worktree: be clearer when "add" dwim-ery kicks in
  worktree: factor out dwim_branch function
  worktree: teach "add" to check out existing branches

 Documentation/git-worktree.txt |  9 ++++-
 builtin/reset.c                |  5 ++-
 builtin/worktree.c             | 85 ++++++++++++++++++++++++++++--------------
 t/t2025-worktree-add.sh        | 25 +++++++++----
 t/t7102-reset.sh               |  5 +++
 5 files changed, 92 insertions(+), 37 deletions(-)

-- 
2.16.1.78.g383dce0c66
Thomas Gummerer· Mar 31, 2018, 15:17 UTC · re: Thomas Gummerer · lore

[PATCH v6 1/6] worktree: remove extra members from struct add_opts

There are two members of 'struct add_opts', which are only used inside the 'add()' function, but being part of 'struct add_opts' they are needlessly also passed to the 'add_worktree' function.

Make them local to the 'add()' function to make it clearer where they are used.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 builtin/worktree.c | 32 +++++++++++++++-----------------
 1 file changed, 15 insertions(+), 17 deletions(-)
Show changes to builtin/worktree.c +15 −17
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 7cef5b120b..4d96a21a45 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -27,8 +27,6 @@ struct add_opts {
 	int detach;
 	int checkout;
 	int keep_locked;
-	const char *new_branch;
-	int force_new_branch;
 };
 
 static int show_only;
@@ -363,10 +361,11 @@ static int add(int ac, const char **av, const char *prefix)
 	const char *new_branch_force = NULL;
 	char *path;
 	const char *branch;
+	const char *new_branch = NULL;
 	const char *opt_track = NULL;
 	struct option options[] = {
 		OPT__FORCE(&opts.force, N_("checkout <branch> even if already checked out in other worktree")),
-		OPT_STRING('b', NULL, &opts.new_branch, N_("branch"),
+		OPT_STRING('b', NULL, &new_branch, N_("branch"),
 			   N_("create a new branch")),
 		OPT_STRING('B', NULL, &new_branch_force, N_("branch"),
 			   N_("create or reset a branch")),
@@ -384,7 +383,7 @@ static int add(int ac, const char **av, const char *prefix)
 	memset(&opts, 0, sizeof(opts));
 	opts.checkout = 1;
 	ac = parse_options(ac, av, prefix, options, worktree_usage, 0);
-	if (!!opts.detach + !!opts.new_branch + !!new_branch_force > 1)
+	if (!!opts.detach + !!new_branch + !!new_branch_force > 1)
 		die(_("-b, -B, and --detach are mutually exclusive"));
 	if (ac < 1 || ac > 2)
 		usage_with_options(worktree_usage, options);
@@ -395,33 +394,32 @@ static int add(int ac, const char **av, const char *prefix)
 	if (!strcmp(branch, "-"))
 		branch = "@{-1}";
 
-	opts.force_new_branch = !!new_branch_force;
-	if (opts.force_new_branch) {
+	if (new_branch_force) {
 		struct strbuf symref = STRBUF_INIT;
 
-		opts.new_branch = new_branch_force;
+		new_branch = new_branch_force;
 
 		if (!opts.force &&
-		    !strbuf_check_branch_ref(&symref, opts.new_branch) &&
+		    !strbuf_check_branch_ref(&symref, new_branch) &&
 		    ref_exists(symref.buf))
 			die_if_checked_out(symref.buf, 0);
 		strbuf_release(&symref);
 	}
 
-	if (ac < 2 && !opts.new_branch && !opts.detach) {
+	if (ac < 2 && !new_branch && !opts.detach) {
 		int n;
 		const char *s = worktree_basename(path, &n);
-		opts.new_branch = xstrndup(s, n);
+		new_branch = xstrndup(s, n);
 		if (guess_remote) {
 			struct object_id oid;
 			const char *remote =
-				unique_tracking_name(opts.new_branch, &oid);
+				unique_tracking_name(new_branch, &oid);
 			if (remote)
 				branch = remote;
 		}
 	}
 
-	if (ac == 2 && !opts.new_branch && !opts.detach) {
+	if (ac == 2 && !new_branch && !opts.detach) {
 		struct object_id oid;
 		struct commit *commit;
 		const char *remote;
@@ -430,25 +428,25 @@ static int add(int ac, const char **av, const char *prefix)
 		if (!commit) {
 			remote = unique_tracking_name(branch, &oid);
 			if (remote) {
-				opts.new_branch = branch;
+				new_branch = branch;
 				branch = remote;
 			}
 		}
 	}
 
-	if (opts.new_branch) {
+	if (new_branch) {
 		struct child_process cp = CHILD_PROCESS_INIT;
 		cp.git_cmd = 1;
 		argv_array_push(&cp.args, "branch");
-		if (opts.force_new_branch)
+		if (new_branch_force)
 			argv_array_push(&cp.args, "--force");
-		argv_array_push(&cp.args, opts.new_branch);
+		argv_array_push(&cp.args, new_branch);
 		argv_array_push(&cp.args, branch);
 		if (opt_track)
 			argv_array_push(&cp.args, opt_track);
 		if (run_command(&cp))
 			return -1;
-		branch = opts.new_branch;
+		branch = new_branch;
 	} else if (opt_track) {
 		die(_("--[no-]track can only be used if a new branch is created"));
 	}

-- 
2.16.1.78.ga2082135d8
Thomas Gummerer· Mar 31, 2018, 15:18 UTC · re: Thomas Gummerer · lore

[PATCH v6 3/6] worktree: improve message when creating a new worktree

Currently 'git worktree add' produces output like the following, when '--no-checkout' is not given:

    Preparing foo (identifier foo)
    HEAD is now at 26da330922 <title>

where the first line is written to stderr, and the second line coming from 'git reset --hard' is written to stdout, even though both lines are supposed to tell the user what has happened. In addition to someone not familiar with 'git worktree', this might seem as if the current HEAD was modified, not the HEAD in the new working tree.

If the '--no-checkout' flag is given, the output of 'git worktree add' is just:

    Preparing foo (identifier foo)
even though the HEAD is set to a commit, which is just not checked out.

The identifier is also not particularly relevant for the user at the moment, as it's only used internally to distinguish between different worktrees that have the same $(basename <path>).

Fix these inconsistencies, and no longer show the identifier by making the 'git reset --hard' call not print the "HEAD is now at ..." line using the newly introduced flag from the previous commit, and printing the message directly from the builtin command instead.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 builtin/worktree.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)
Show changes to builtin/worktree.c +10 −2
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 4d96a21a45..cc94325886 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -301,8 +301,6 @@ static int add_worktree(const char *path, const char *refname,
 	strbuf_addf(&sb, "%s/commondir", sb_repo.buf);
 	write_file(sb.buf, "../..");
 
-	fprintf_ln(stderr, _("Preparing %s (identifier %s)"), path, name);
-
 	argv_array_pushf(&child_env, "%s=%s", GIT_DIR_ENVIRONMENT, sb_git.buf);
 	argv_array_pushf(&child_env, "%s=%s", GIT_WORK_TREE_ENVIRONMENT, path);
 	cp.git_cmd = 1;
@@ -322,12 +320,22 @@ static int add_worktree(const char *path, const char *refname,
 		cp.argv = NULL;
 		argv_array_clear(&cp.args);
 		argv_array_pushl(&cp.args, "reset", "--hard", NULL);
+		argv_array_push(&cp.args, "--no-show-new-head-line");
 		cp.env = child_env.argv;
 		ret = run_command(&cp);
 		if (ret)
 			goto done;
 	}
 
+	fprintf(stderr, _("New worktree HEAD is now at %s"),
+		find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
+
+	strbuf_reset(&sb);
+	pp_commit_easy(CMIT_FMT_ONELINE, commit, &sb);
+	if (sb.len > 0)
+		fprintf(stderr, " %s", sb.buf);
+	fputc('\n', stderr);
+
 	is_junk = 0;
 	FREE_AND_NULL(junk_work_tree);
 	FREE_AND_NULL(junk_git_dir);

-- 
2.16.1.78.ga2082135d8
Eric Sunshine· Apr 8, 2018, 09:27 UTC · re: Thomas Gummerer · lore

Re: [PATCH v6 3/6] worktree: improve message when creating a new worktree

On Sat, Mar 31, 2018 at 11:18 AM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
Show 30 quoted lines
> [...]
> Fix these inconsistencies, and no longer show the identifier by making
> the 'git reset --hard' call not print the "HEAD is now at ..." line
> using the newly introduced flag from the previous commit, and printing
> the message directly from the builtin command instead.
>
> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
> ---
> diff --git a/builtin/worktree.c b/builtin/worktree.c
> @@ -322,12 +320,22 @@ static int add_worktree(const char *path, const char *refname,
>                 argv_array_pushl(&cp.args, "reset", "--hard", NULL);
> +               argv_array_push(&cp.args, "--no-show-new-head-line");
>                 cp.env = child_env.argv;
>                 ret = run_command(&cp);
>                 if (ret)
>                         goto done;
>         }
>
> +       fprintf(stderr, _("New worktree HEAD is now at %s"),
> +               find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
> +
> +       strbuf_reset(&sb);
> +       pp_commit_easy(CMIT_FMT_ONELINE, commit, &sb);
> +       if (sb.len > 0)
> +               fprintf(stderr, " %s", sb.buf);
> +       fputc('\n', stderr);
> +
>         is_junk = 0;
>         FREE_AND_NULL(junk_work_tree);
>         FREE_AND_NULL(junk_git_dir);

Generally speaking, code such as this probably ought to be inserted outside of the is_junk={1,0} context in order to keep that critical section as small as possible. However, as mentioned in my response to the v6 cover letter[1], I think this chunk of new code can just go away entirely if git-reset is made to print the customized message on git-worktree's behalf.

[1]: https://public-inbox.org/git/CAPig+cQ8VzDycUMo-QOexNDBgQGEGj2BPmPa-Y0vhGCt_brbhg@mail.gmail.com/
Thomas Gummerer· Mar 31, 2018, 15:18 UTC · re: Thomas Gummerer · lore

[PATCH v6 2/6] reset: introduce show-new-head-line option

Introduce a new --show-new-head-line command line option, that determines whether the "HEAD is now at ..." message is printed or not. It is enabled by default to preserve the current behaviour.

It will be used in a subsequent commit to disable printing the "HEAD is now at ..." line in 'git worktree add', so it can be replaced with a custom one, that explains the behaviour better.

We cannot just pass the --quite flag from 'git worktree add', as that would also hide progress output when checking out large working trees, which is undesirable.

As this option is only for internal use, which we probably don't want to advertise to our users, at least until there's a need for it, make it a hidden flag.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 builtin/reset.c  | 5 ++++-
 t/t7102-reset.sh | 5 +++++
 2 files changed, 9 insertions(+), 1 deletion(-)
Show changes to 2 files +9 −1

builtin/reset.c, t/t7102-reset.sh

diff --git a/builtin/reset.c b/builtin/reset.c
index e15f595799..54b2576449 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -288,6 +288,7 @@ static int git_reset_config(const char *var, const char *value, void *cb)
 int cmd_reset(int argc, const char **argv, const char *prefix)
 {
 	int reset_type = NONE, update_ref_status = 0, quiet = 0;
+	int show_new_head_line = 1;
 	int patch_mode = 0, unborn;
 	const char *rev;
 	struct object_id oid;
@@ -310,6 +311,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
 		OPT_BOOL('p', "patch", &patch_mode, N_("select hunks interactively")),
 		OPT_BOOL('N', "intent-to-add", &intent_to_add,
 				N_("record only the fact that removed paths will be added later")),
+		OPT_HIDDEN_BOOL(0, "show-new-head-line", &show_new_head_line, N_("show information on the new HEAD")),
 		OPT_END()
 	};
 
@@ -403,7 +405,8 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
 		 * switched to, saving the previous head in ORIG_HEAD before. */
 		update_ref_status = reset_refs(rev, &oid);
 
-		if (reset_type == HARD && !update_ref_status && !quiet)
+		if (reset_type == HARD && !update_ref_status && !quiet &&
+		    show_new_head_line)
 			print_new_head_line(lookup_commit_reference(&oid));
 	}
 	if (!pathspec.nr)
diff --git a/t/t7102-reset.sh b/t/t7102-reset.sh
index 95653a08ca..a160f78aba 100755
--- a/t/t7102-reset.sh
+++ b/t/t7102-reset.sh
@@ -568,4 +568,9 @@ test_expect_success 'reset --mixed sets up work tree' '
 	test_cmp expect actual
 '
 
+test_expect_success 'reset --no-show-new-head-line suppresses "HEAD is now at" output' '
+	git reset --hard --no-show-new-head-line HEAD >actual &&
+	! grep "HEAD is now at" <actual
+'
+
 test_done

-- 
2.16.1.78.ga2082135d8
Junio C Hamano· Apr 2, 2018, 20:29 UTC · re: Thomas Gummerer · lore

Re: [PATCH v6 2/6] reset: introduce show-new-head-line option

Thomas Gummerer <t.gummerer@gmail.com> writes:
Show 15 quoted lines
> Introduce a new --show-new-head-line command line option, that
> determines whether the "HEAD is now at ..." message is printed or not.
> It is enabled by default to preserve the current behaviour.
>
> It will be used in a subsequent commit to disable printing the "HEAD is
> now at ..." line in 'git worktree add', so it can be replaced with a
> custom one, that explains the behaviour better.
>
> We cannot just pass the --quite flag from 'git worktree add', as that
> would also hide progress output when checking out large working trees,
> which is undesirable.
>
> As this option is only for internal use, which we probably don't want
> to advertise to our users, at least until there's a need for it, make
> it a hidden flag.

As a temporary hack, adding something like this may be OK, but in the longer run, I think we should (at least) consider refactoring "reset --hard" codepath to a freestanding and silent helper function so that both cmd_reset() and add_worktree() can call it and report the outcome in their own phrasing.

And I support the decision not to advertise this as a new feature or an option by implementing it as hidden-bool.

This is completely offtopic tangent, but I wonder how hidden-bool or hidden options[] element in general interacts with the recent addition of helping command line completion. Are we already doing the right thing?

Thomas Gummerer· Apr 2, 2018, 22:07 UTC · re: Junio C Hamano · lore

Re: [PATCH v6 2/6] reset: introduce show-new-head-line option

On 04/02, Junio C Hamano wrote:
Show 23 quoted lines
> Thomas Gummerer <t.gummerer@gmail.com> writes:
> 
> > Introduce a new --show-new-head-line command line option, that
> > determines whether the "HEAD is now at ..." message is printed or not.
> > It is enabled by default to preserve the current behaviour.
> >
> > It will be used in a subsequent commit to disable printing the "HEAD is
> > now at ..." line in 'git worktree add', so it can be replaced with a
> > custom one, that explains the behaviour better.
> >
> > We cannot just pass the --quite flag from 'git worktree add', as that
> > would also hide progress output when checking out large working trees,
> > which is undesirable.
> >
> > As this option is only for internal use, which we probably don't want
> > to advertise to our users, at least until there's a need for it, make
> > it a hidden flag.
> 
> As a temporary hack, adding something like this may be OK, but in
> the longer run, I think we should (at least) consider refactoring
> "reset --hard" codepath to a freestanding and silent helper function
> so that both cmd_reset() and add_worktree() can call it and report
> the outcome in their own phrasing.

I agree that refactoring this would have been nicer. The biggest obstacle there is that the 'git reset' needs to run with a different "GIT_DIR" and "GIT_WORK_TREE", which is not easy to accomplish in the current code.

It does seem like something that would be much easier once we have 'struct repository' being passed through everywhere. I'd rather wait a bit more for the 'struct repository' series to land, which will hopefully make the refactoring easier (although I didn't have time to follow the series closely).

Show 7 quoted lines
> And I support the decision not to advertise this as a new feature or
> an option by implementing it as hidden-bool.
> 
> This is completely offtopic tangent, but I wonder how hidden-bool or
> hidden options[] element in general interacts with the recent
> addition of helping command line completion.  Are we already doing
> the right thing?
Thomas Gummerer· Apr 2, 2018, 22:20 UTC · re: Junio C Hamano · lore

Re: [PATCH v6 2/6] reset: introduce show-new-head-line option

On 04/02, Junio C Hamano wrote:
> This is completely offtopic tangent, but I wonder how hidden-bool or
> hidden options[] element in general interacts with the recent
> addition of helping command line completion.  Are we already doing
> the right thing?

I had a quick look at this, and it looks like we're doing the right thing here. The following snipped from the 'show_gitcomp' function in parse-options.c:

Show 7 quoted lines
>	for (; opts->type != OPTION_END; opts++) {
>		const char *suffix = "";
>
>		if (!opts->long_name)
>			continue;
>		if (opts->flags & (PARSE_OPT_HIDDEN | PARSE_OPT_NOCOMPLETE))
>			continue;

So if the PARSE_OPT_HIDDEN flag is given, we skip printing the option, which seems like the right thing to do.

Junio C Hamano· Apr 2, 2018, 20:34 UTC · re: Thomas Gummerer · lore

Re: [PATCH v6 2/6] reset: introduce show-new-head-line option

Thomas Gummerer <t.gummerer@gmail.com> writes:
> +test_expect_success 'reset --no-show-new-head-line suppresses "HEAD is now at" output' '
> +	git reset --hard --no-show-new-head-line HEAD >actual &&
> +	! grep "HEAD is now at" <actual
> +'
As builtin/reset.c::print_new_head_line() does this:
	printf(_("HEAD is now at %s"), hex);
this needs to use "test_i18ngrep !" instead, no?
Thomas Gummerer· Apr 2, 2018, 22:09 UTC · re: Junio C Hamano · lore

Re: [PATCH v6 2/6] reset: introduce show-new-head-line option

On 04/02, Junio C Hamano wrote:
Show 12 quoted lines
> Thomas Gummerer <t.gummerer@gmail.com> writes:
> 
> > +test_expect_success 'reset --no-show-new-head-line suppresses "HEAD is now at" output' '
> > +	git reset --hard --no-show-new-head-line HEAD >actual &&
> > +	! grep "HEAD is now at" <actual
> > +'
> 
> As builtin/reset.c::print_new_head_line() does this:
> 
> 	printf(_("HEAD is now at %s"), hex);
> 
> this needs to use "test_i18ngrep !" instead, no?
Ah yes you're right.  Thanks for catching this.
Thomas Gummerer· Mar 31, 2018, 15:18 UTC · re: Thomas Gummerer · lore

[PATCH v6 6/6] worktree: teach "add" to check out existing branches

Currently 'git worktree add <path>' creates a new branch named after the basename of the path by default. If a branch with that name already exists, the command refuses to do anything, unless the '--force' option is given.

However we can do a little better than that, and check the branch out if it is not checked out anywhere else. This will help users who just want to check an existing branch out into a new worktree, and save a few keystrokes.

As the current behaviour is to simply 'die()' when a branch with the name of the basename of the path already exists, there are no backwards compatibility worries here.

We will still 'die()' if the branch is checked out in another worktree, unless the --force flag is passed.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 Documentation/git-worktree.txt |  9 +++++++--
 builtin/worktree.c             | 22 +++++++++++++++++++---
 t/t2025-worktree-add.sh        | 25 ++++++++++++++++++-------
 3 files changed, 44 insertions(+), 12 deletions(-)
Show changes to 3 files +44 −12

Documentation/git-worktree.txt, builtin/worktree.c, t/t2025-worktree-add.sh

diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index 41585f535d..eaa6bf713f 100644
--- a/Documentation/git-worktree.txt
+++ b/Documentation/git-worktree.txt
@@ -61,8 +61,13 @@ $ git worktree add --track -b <branch> <path> <remote>/<branch>
 ------------
 +
 If `<commit-ish>` is omitted and neither `-b` nor `-B` nor `--detach` used,
-then, as a convenience, a new branch based at HEAD is created automatically,
-as if `-b $(basename <path>)` was specified.
+then, as a convenience, a worktree with a branch named after
+`$(basename <path>)` (call it `<branch>`) is created.  If `<branch>`
+doesn't exist, a new branch based on HEAD is automatically created as
+if `-b <branch>` was given.  If `<branch>` exists in the repository,
+it will be checked out in the new worktree, if it's not checked out
+anywhere else, otherwise the command will refuse to create the
+worktree (unless `--force` is used).
 
 list::
 
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 47189d50dd..511d0aa370 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -363,11 +363,23 @@ static int add_worktree(const char *path, const char *refname,
 	return ret;
 }
 
-static const char *dwim_branch(const char *path, const char **new_branch)
+static const char *dwim_branch(const char *path, const char **new_branch,
+			       int *checkout_existing_branch)
 {
 	int n;
 	const char *s = worktree_basename(path, &n);
-	*new_branch = xstrndup(s, n);
+	const char *branchname = xstrndup(s, n);
+	struct strbuf ref = STRBUF_INIT;
+
+	if (!strbuf_check_branch_ref(&ref, branchname) &&
+	    ref_exists(ref.buf)) {
+		*checkout_existing_branch = 1;
+		strbuf_release(&ref);
+		UNLEAK(branchname);
+		return branchname;
+	}
+
+	*new_branch = branchname;
 	if (guess_remote) {
 		struct object_id oid;
 		const char *remote =
@@ -385,6 +397,7 @@ static int add(int ac, const char **av, const char *prefix)
 	const char *branch;
 	const char *new_branch = NULL;
 	const char *opt_track = NULL;
+	int checkout_existing_branch = 0;
 	struct option options[] = {
 		OPT__FORCE(&opts.force, N_("checkout <branch> even if already checked out in other worktree")),
 		OPT_STRING('b', NULL, &new_branch, N_("branch"),
@@ -429,7 +442,8 @@ static int add(int ac, const char **av, const char *prefix)
 	}
 
 	if (ac < 2 && !new_branch && !opts.detach) {
-		const char *s = dwim_branch(path, &new_branch);
+		const char *s = dwim_branch(path, &new_branch,
+					    &checkout_existing_branch);
 		if (s)
 			branch = s;
 	}
@@ -464,6 +478,8 @@ static int add(int ac, const char **av, const char *prefix)
 		if (run_command(&cp))
 			return -1;
 		branch = new_branch;
+	} else if (checkout_existing_branch) {
+		  fprintf_ln(stderr, _("Checking out branch '%s'"), branch);
 	} else if (opt_track) {
 		die(_("--[no-]track can only be used if a new branch is created"));
 	}
diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
index 2b95944973..f72cb0eb0b 100755
--- a/t/t2025-worktree-add.sh
+++ b/t/t2025-worktree-add.sh
@@ -198,13 +198,24 @@ test_expect_success '"add" with <branch> omitted' '
 	test_cmp_rev HEAD bat
 '
 
-test_expect_success '"add" auto-vivify does not clobber existing branch' '
-	test_commit c1 &&
-	test_commit c2 &&
-	git branch precious HEAD~1 &&
-	test_must_fail git worktree add precious &&
-	test_cmp_rev HEAD~1 precious &&
-	test_path_is_missing precious
+test_expect_success '"add" checks out existing branch of dwimd name' '
+	git branch dwim HEAD~1 &&
+	git worktree add dwim &&
+	test_cmp_rev HEAD~1 dwim &&
+	(
+		cd dwim &&
+		test_cmp_rev dwim HEAD
+	)
+'
+
+test_expect_success '"add <path>" dwim fails with checked out branch' '
+	git checkout -b test-branch &&
+	test_must_fail git worktree add test-branch &&
+	test_path_is_missing test-branch
+'
+
+test_expect_success '"add --force" with existing dwimd name doesnt die' '
+	git worktree add --force test-branch
 '
 
 test_expect_success '"add" no auto-vivify with --detach and <branch> omitted' '

-- 
2.16.1.78.ga2082135d8
Thomas Gummerer· Apr 1, 2018, 13:11 UTC · re: Thomas Gummerer · lore

[PATCH v6 6.5/6] fixup! worktree: teach "add" to check out existing branches

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---

So while playing with it a bit more I found one case where the new UI is not ideal and a bit confusing. Namely when the new check out dwim kicks in, but there is already a file/directory at the path we're giving to 'git worktree add'.

In that case something like the following would be printed:
    $ g worktree add ../next
    Checking out branch 'next'
    fatal: '../next' already exists

Instead I think we'd just want the error without the "Checking out branch" message, which is what this fixup here does.

One thing that gets a bit strange is that the "Checking out branch" message and the "Creating branch" messages are printed from different places. But without doing quite some refactoring I don't think there's a good way to do that, and I think having the UI do the right thing is more important.

One thing I also noticed is that if a branch is created by 'git worktree add', but we fail, we never clean up that branch again, which I'm not sure is ideal. As a pre-existing problem I'd like to keep fixing that out of the scope of this series though (at least after this series the user would get some output showing that this happened, even when the branch is not set up to track a remote), so I'd like to keep fixing that out of the scope of this series.

Junio: could you please squash this in in 6/6 while queuing?  I'd
prefer not to re-send the whole series just for fixing this up, but
obviously can if that makes your life easier :)
Thanks!
 builtin/worktree.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
Show changes to builtin/worktree.c +4 −4
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 511d0aa370..ccc2e63e0f 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -27,6 +27,7 @@ struct add_opts {
 	int detach;
 	int checkout;
 	int keep_locked;
+	int checkout_existing_branch;
 };
 
 static int show_only;
@@ -316,6 +317,8 @@ static int add_worktree(const char *path, const char *refname,
 	if (ret)
 		goto done;
 
+	if (opts->checkout_existing_branch)
+		  fprintf_ln(stderr, _("Checking out branch '%s'"), refname);
 	if (opts->checkout) {
 		cp.argv = NULL;
 		argv_array_clear(&cp.args);
@@ -397,7 +400,6 @@ static int add(int ac, const char **av, const char *prefix)
 	const char *branch;
 	const char *new_branch = NULL;
 	const char *opt_track = NULL;
-	int checkout_existing_branch = 0;
 	struct option options[] = {
 		OPT__FORCE(&opts.force, N_("checkout <branch> even if already checked out in other worktree")),
 		OPT_STRING('b', NULL, &new_branch, N_("branch"),
@@ -443,7 +445,7 @@ static int add(int ac, const char **av, const char *prefix)
 
 	if (ac < 2 && !new_branch && !opts.detach) {
 		const char *s = dwim_branch(path, &new_branch,
-					    &checkout_existing_branch);
+					    &opts.checkout_existing_branch);
 		if (s)
 			branch = s;
 	}
@@ -478,8 +480,6 @@ static int add(int ac, const char **av, const char *prefix)
 		if (run_command(&cp))
 			return -1;
 		branch = new_branch;
-	} else if (checkout_existing_branch) {
-		  fprintf_ln(stderr, _("Checking out branch '%s'"), branch);
 	} else if (opt_track) {
 		die(_("--[no-]track can only be used if a new branch is created"));
 	}

-- 
2.16.1.78.g71f731ae26.dirty
Eric Sunshine· Apr 9, 2018, 00:23 UTC · re: Thomas Gummerer · lore

Re: [PATCH v6 6.5/6] fixup! worktree: teach "add" to check out existing branches

On Sun, Apr 1, 2018 at 9:11 AM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
Show 13 quoted lines
> So while playing with it a bit more I found one case where the new UI
> is not ideal and a bit confusing.  Namely when the new check out dwim
> kicks in, but there is already a file/directory at the path we're
> giving to 'git worktree add'.
>
> In that case something like the following would be printed:
>
>     $ g worktree add ../next
>     Checking out branch 'next'
>     fatal: '../next' already exists
>
> Instead I think we'd just want the error without the "Checking out
> branch" message, which is what this fixup here does.
Doesn't the same UI "problem" exist when it creates a new branch?
    $ git worktree add ../dwim
    Creating branch 'dwim'
    fatal: '../dwim' already exists

As you mention below, we don't (yet) clean up the newly-created branch upon failure, so we can't suppress the "Creating branch" message as you suppress the "Checking out branch" message above (since the user needs to know that the new branch exists).

This is making me wonder if "Checking out branch" is perhaps the wrong terminology. What if it said something like this instead:

    $ git worktree add ../next
    Preparing worktree (branch 'next' <= 'origin/next')
    fatal: '../next' already exists
    $ git worktree add ../gobble
    Preparing worktree (new branch 'gobble')
    fatal: '../gobble' already exists

This way, we don't need the special case added by this "fixup!" patch. (I'm not wedded to the "Preparing" message but just used it as an example; better suggestions welcome.)

Show 5 quoted lines
> One thing that gets a bit strange is that the "Checking out branch"
> message and the "Creating branch" messages are printed from different
> places.  But without doing quite some refactoring I don't think
> there's a good way to do that, and I think having the UI do the right
> thing is more important.

The implementation is getting rather ugly, though, especially with these messages being printed by different bits of code like this. worktree.c:add_worktree() was supposed to be the low-level worker; it wasn't intended for it to take on UI duties like this "fixup!" makes it do. UI should be handled by worktree.c:add().

Taking the above "Preparing..." idea into consideration, then it should be possible to sidestep this implementation ugliness, I would think.

Show 7 quoted lines
> One thing I also noticed is that if a branch is created by 'git
> worktree add', but we fail, we never clean up that branch again, which
> I'm not sure is ideal.  As a pre-existing problem I'd like to keep
> fixing that out of the scope of this series though (at least after
> this series the user would get some output showing that this happened,
> even when the branch is not set up to track a remote), so I'd like to
> keep fixing that out of the scope of this series.
Nice idea, but outside the scope of this series, as you mention.
Show 9 quoted lines
> diff --git a/builtin/worktree.c b/builtin/worktree.c
> @@ -27,6 +27,7 @@ struct add_opts {
>         int keep_locked;
> +       int checkout_existing_branch;
>  };
> @@ -316,6 +317,8 @@ static int add_worktree(const char *path, const char *refname,
> +       if (opts->checkout_existing_branch)
> +                 fprintf_ln(stderr, _("Checking out branch '%s'"), refname);
>         if (opts->checkout) {

I'd have expected to see the "if (opts->checkout_existing_branch) fprintf_ln(...)" inside the following "if (opts->checkout)" conditional, though, as noted above, I'm not entirely happy about worktree.c:add_worktree() taking on UI duties.

>                 cp.argv = NULL;
>                 argv_array_clear(&cp.args);
Thomas Gummerer· Apr 9, 2018, 19:44 UTC · re: Eric Sunshine · lore

Re: [PATCH v6 6.5/6] fixup! worktree: teach "add" to check out existing branches

On 04/08, Eric Sunshine wrote:
Show 40 quoted lines
> On Sun, Apr 1, 2018 at 9:11 AM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
> > So while playing with it a bit more I found one case where the new UI
> > is not ideal and a bit confusing.  Namely when the new check out dwim
> > kicks in, but there is already a file/directory at the path we're
> > giving to 'git worktree add'.
> >
> > In that case something like the following would be printed:
> >
> >     $ g worktree add ../next
> >     Checking out branch 'next'
> >     fatal: '../next' already exists
> >
> > Instead I think we'd just want the error without the "Checking out
> > branch" message, which is what this fixup here does.
> 
> Doesn't the same UI "problem" exist when it creates a new branch?
> 
>     $ git worktree add ../dwim
>     Creating branch 'dwim'
>     fatal: '../dwim' already exists
> 
> As you mention below, we don't (yet) clean up the newly-created branch
> upon failure, so we can't suppress the "Creating branch" message as
> you suppress the "Checking out branch" message above (since the user
> needs to know that the new branch exists).
> 
> This is making me wonder if "Checking out branch" is perhaps the wrong
> terminology. What if it said something like this instead:
> 
>     $ git worktree add ../next
>     Preparing worktree (branch 'next' <= 'origin/next')
>     fatal: '../next' already exists
> 
>     $ git worktree add ../gobble
>     Preparing worktree (new branch 'gobble')
>     fatal: '../gobble' already exists
> 
> This way, we don't need the special case added by this "fixup!" patch.
> (I'm not wedded to the "Preparing" message but just used it as an
> example; better suggestions welcome.)

Yeah, I think this looks like another improvement of what I currently have. I'm not sure about the "(branch 'next' <= 'origin/next')" message though, as it doesn't cover all the ways the branch could be set up for tracking the remote branch, e.g. tracking by rebasing, when 'branch.autosetuprebase' is set up.

But how about just "Preparing worktree (new branch 'next')", and then keeping the message from 'git branch' about setting up the remote tracking branch?

Show 40 quoted lines
> > One thing that gets a bit strange is that the "Checking out branch"
> > message and the "Creating branch" messages are printed from different
> > places.  But without doing quite some refactoring I don't think
> > there's a good way to do that, and I think having the UI do the right
> > thing is more important.
> 
> The implementation is getting rather ugly, though, especially with
> these messages being printed by different bits of code like this.
> worktree.c:add_worktree() was supposed to be the low-level worker; it
> wasn't intended for it to take on UI duties like this "fixup!" makes
> it do. UI should be handled by worktree.c:add().
> 
> Taking the abonve "Preparing..." idea into consideration, then it
> should be possible to sidestep this implementation ugliness, I would
> think.
> 
> > One thing I also noticed is that if a branch is created by 'git
> > worktree add', but we fail, we never clean up that branch again, which
> > I'm not sure is ideal.  As a pre-existing problem I'd like to keep
> > fixing that out of the scope of this series though (at least after
> > this series the user would get some output showing that this happened,
> > even when the branch is not set up to track a remote), so I'd like to
> > keep fixing that out of the scope of this series.
> 
> Nice idea, but outside the scope of this series, as you mention.
> 
> > diff --git a/builtin/worktree.c b/builtin/worktree.c
> > @@ -27,6 +27,7 @@ struct add_opts {
> >         int keep_locked;
> > +       int checkout_existing_branch;
> >  };
> > @@ -316,6 +317,8 @@ static int add_worktree(const char *path, const char *refname,
> > +       if (opts->checkout_existing_branch)
> > +                 fprintf_ln(stderr, _("Checking out branch '%s'"), refname);
> >         if (opts->checkout) {
> 
> I'd have expected to see the "if (opts->checkout_existing_branch)
> fprintf_ln(...)" inside the following "if (opts->checkout)"
> conditional, though, as noted above, I'm not entirely happy about
> worktree.c:add_worktree() taking on UI duties.

Fair enough. I didn't quite like the code either. I think what you have above would be much nicer, and I'll implement that in the re-roll.

> >                 cp.argv = NULL;
> >                 argv_array_clear(&cp.args);
Eric Sunshine· Apr 9, 2018, 21:35 UTC · re: Thomas Gummerer · lore

Re: [PATCH v6 6.5/6] fixup! worktree: teach "add" to check out existing branches

On Mon, Apr 9, 2018 at 3:44 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
Show 21 quoted lines
> On 04/08, Eric Sunshine wrote:
>> This is making me wonder if "Checking out branch" is perhaps the wrong
>> terminology. What if it said something like this instead:
>>
>>     $ git worktree add ../next
>>     Preparing worktree (branch 'next' <= 'origin/next')
>>     fatal: '../next' already exists
>>
>> This way, we don't need the special case added by this "fixup!" patch.
>> (I'm not wedded to the "Preparing" message but just used it as an
>> example; better suggestions welcome.)
>
> Yeah, I think this looks like another improvement of what I currently
> have.  I'm not sure about the "(branch 'next' <= 'origin/next')"
> message though, as it doesn't cover all the ways the branch could be
> set up for tracking the remote branch, e.g. tracking by rebasing, when
> 'branch.autosetuprebase' is set up.
>
> But how about just "Preparing worktree (new branch 'next')", and then
> keeping the message from 'git branch' about setting up the remote
> tracking branch?

Fair enough. Extra annotation (such as "'foo' <= 'bar'" or whatever) can always be added later if someone wants it.

Eric Sunshine· Apr 8, 2018, 10:09 UTC · re: Thomas Gummerer · lore

Re: [PATCH v6 6/6] worktree: teach "add" to check out existing branches

On Sat, Mar 31, 2018 at 11:18 AM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
Show 13 quoted lines
> [...]
> However we can do a little better than that, and check the branch out if
> it is not checked out anywhere else.  This will help users who just want
> to check an existing branch out into a new worktree, and save a few
> keystrokes.
> [...]
> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
> ---
> diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
> @@ -61,8 +61,13 @@ $ git worktree add --track -b <branch> <path> <remote>/<branch>
>  If `<commit-ish>` is omitted and neither `-b` nor `-B` nor `--detach` used,
> +then, as a convenience, a worktree with a branch named after
> +`$(basename <path>)` (call it `<branch>`) is created.
I had a hard time digesting this. I _think_ it wants to say:
    If `<commit-ish>` is omitted and neither `-b` nor `-B` nor
    `--detach` is used, then, as a convenience, the new worktree is
    associated with a branch (call it `<branch>`) named after
    `$(basename <path>)`.
>  If `<branch>`
> +doesn't exist, a new branch based on HEAD is automatically created as
> +if `-b <branch>` was given.  If `<branch>` exists in the repository,
Maybe: s/exists in the repository/does exist/
Or: s/.../is a local branch/
Though, the latter may be getting too pedantic.
Show 12 quoted lines
> +it will be checked out in the new worktree, if it's not checked out
> +anywhere else, otherwise the command will refuse to create the
> +worktree (unless `--force` is used).
> diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
> @@ -198,13 +198,24 @@ test_expect_success '"add" with <branch> omitted' '
> +test_expect_success '"add" checks out existing branch of dwimd name' '
> +       git branch dwim HEAD~1 &&
> +       git worktree add dwim &&
> +       test_cmp_rev HEAD~1 dwim &&
> +       (
> +               cd dwim &&
> +               test_cmp_rev dwim HEAD
Nit: Argument order of the two test_cmp_rev() invocations differs.
Show 12 quoted lines
> +       )
> +'
> +
> +test_expect_success '"add <path>" dwim fails with checked out branch' '
> +       git checkout -b test-branch &&
> +       test_must_fail git worktree add test-branch &&
> +       test_path_is_missing test-branch
> +'
> +
> +test_expect_success '"add --force" with existing dwimd name doesnt die' '
> +       git worktree add --force test-branch
>  '

Maybe make this last test slightly more robust by having it "git checkout test-branch" before "git worktree add ..." to protect against someone inserting a new test (which checks out some other branch) between these two. Probably not worth a re-roll.

Thomas Gummerer· Apr 8, 2018, 14:30 UTC · re: Eric Sunshine · lore

Re: [PATCH v6 6/6] worktree: teach "add" to check out existing branches

On 04/08, Eric Sunshine wrote:
Show 21 quoted lines
> On Sat, Mar 31, 2018 at 11:18 AM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
> > [...]
> > However we can do a little better than that, and check the branch out if
> > it is not checked out anywhere else.  This will help users who just want
> > to check an existing branch out into a new worktree, and save a few
> > keystrokes.
> > [...]
> > Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
> > ---
> > diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
> > @@ -61,8 +61,13 @@ $ git worktree add --track -b <branch> <path> <remote>/<branch>
> >  If `<commit-ish>` is omitted and neither `-b` nor `-B` nor `--detach` used,
> > +then, as a convenience, a worktree with a branch named after
> > +`$(basename <path>)` (call it `<branch>`) is created.
> 
> I had a hard time digesting this. I _think_ it wants to say:
> 
>     If `<commit-ish>` is omitted and neither `-b` nor `-B` nor
>     `--detach` is used, then, as a convenience, the new worktree is
>     associated with a branch (call it `<branch>`) named after
>     `$(basename <path>)`.

Yeah, this is what it wants to say, and what you have sounds much nicer, will change.

Show 41 quoted lines
> >  If `<branch>`
> > +doesn't exist, a new branch based on HEAD is automatically created as
> > +if `-b <branch>` was given.  If `<branch>` exists in the repository,
> 
> Maybe: s/exists in the repository/does exist/
> Or: s/.../is a local branch/
> 
> Though, the latter may be getting too pedantic.
> 
> > +it will be checked out in the new worktree, if it's not checked out
> > +anywhere else, otherwise the command will refuse to create the
> > +worktree (unless `--force` is used).
> > diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
> > @@ -198,13 +198,24 @@ test_expect_success '"add" with <branch> omitted' '
> > +test_expect_success '"add" checks out existing branch of dwimd name' '
> > +       git branch dwim HEAD~1 &&
> > +       git worktree add dwim &&
> > +       test_cmp_rev HEAD~1 dwim &&
> > +       (
> > +               cd dwim &&
> > +               test_cmp_rev dwim HEAD
> 
> Nit: Argument order of the two test_cmp_rev() invocations differs.
> 
> > +       )
> > +'
> > +
> > +test_expect_success '"add <path>" dwim fails with checked out branch' '
> > +       git checkout -b test-branch &&
> > +       test_must_fail git worktree add test-branch &&
> > +       test_path_is_missing test-branch
> > +'
> > +
> > +test_expect_success '"add --force" with existing dwimd name doesnt die' '
> > +       git worktree add --force test-branch
> >  '
> 
> Maybe make this last test slightly more robust by having it "git
> checkout test-branch" before "git worktree add ..." to protect against
> someone inserting a new test (which checks out some other branch)
> between these two. Probably not worth a re-roll.

As I'll have to re-roll anyway for the other suggestions, I'll change this as well.

Thanks for your review!
Thomas Gummerer· Mar 31, 2018, 15:18 UTC · re: Thomas Gummerer · lore

[PATCH v6 4/6] worktree: be clearer when "add" dwim-ery kicks in

Currently there is no indication in the "git worktree add" output that a new branch was created. This would be especially useful information in the case where the dwim of "git worktree add <path>" kicks in, as the user didn't explicitly ask for a new branch, but we create one for them.

Print some additional output showing that a branch was created and the branch name to help the user.

This will also be useful in a subsequent commit, which introduces a new kind of dwim-ery of checking out the branch if it exists instead of refusing to create a new worktree in that case, and where it's nice to tell the user which kind of dwim-ery kicked in.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 builtin/worktree.c | 2 ++
 1 file changed, 2 insertions(+)
Show changes to builtin/worktree.c +2 −0
diff --git a/builtin/worktree.c b/builtin/worktree.c
index cc94325886..f686ee1440 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -444,6 +444,8 @@ static int add(int ac, const char **av, const char *prefix)
 
 	if (new_branch) {
 		struct child_process cp = CHILD_PROCESS_INIT;
+
+		fprintf_ln(stderr, _("Creating branch '%s'"), new_branch);
 		cp.git_cmd = 1;
 		argv_array_push(&cp.args, "branch");
 		if (new_branch_force)

-- 
2.16.1.78.ga2082135d8
Thomas Gummerer· Mar 31, 2018, 15:18 UTC · re: Thomas Gummerer · lore

[PATCH v6 5/6] worktree: factor out dwim_branch function

Factor out a dwim_branch function, which takes care of the dwim'ery in 'git worktree add <path>'. It's not too much code currently, but we're adding a new kind of dwim in a subsequent patch, at which point it makes more sense to have it as a separate function.

Factor it out now to reduce the patch noise in the next patch.
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 builtin/worktree.c | 27 +++++++++++++++++----------
 1 file changed, 17 insertions(+), 10 deletions(-)
Show changes to builtin/worktree.c +17 −10
diff --git a/builtin/worktree.c b/builtin/worktree.c
index f686ee1440..47189d50dd 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -363,6 +363,20 @@ static int add_worktree(const char *path, const char *refname,
 	return ret;
 }
 
+static const char *dwim_branch(const char *path, const char **new_branch)
+{
+	int n;
+	const char *s = worktree_basename(path, &n);
+	*new_branch = xstrndup(s, n);
+	if (guess_remote) {
+		struct object_id oid;
+		const char *remote =
+			unique_tracking_name(*new_branch, &oid);
+		return remote;
+	}
+	return NULL;
+}
+
 static int add(int ac, const char **av, const char *prefix)
 {
 	struct add_opts opts;
@@ -415,16 +429,9 @@ static int add(int ac, const char **av, const char *prefix)
 	}
 
 	if (ac < 2 && !new_branch && !opts.detach) {
-		int n;
-		const char *s = worktree_basename(path, &n);
-		new_branch = xstrndup(s, n);
-		if (guess_remote) {
-			struct object_id oid;
-			const char *remote =
-				unique_tracking_name(new_branch, &oid);
-			if (remote)
-				branch = remote;
-		}
+		const char *s = dwim_branch(path, &new_branch);
+		if (s)
+			branch = s;
 	}
 
 	if (ac == 2 && !new_branch && !opts.detach) {

-- 
2.16.1.78.ga2082135d8
Eric Sunshine· Apr 8, 2018, 09:08 UTC · re: Thomas Gummerer · lore

Re: [PATCH v6 0/6] worktree: teach "add" to check out existing branches

On Sat, Mar 31, 2018 at 11:17 AM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
Show 8 quoted lines
> This round should fix all the UI issues Eric found in the last round.
> The changes I made in a bit more detail:
>
> - added a new commit introducing a new hidden --show-new-head-line
>   flag in 'git reset'.  This is used to suppress the "HEAD is now at
>   ..."  line that 'git reset --hard' usually prints, so we can replace
>   it with our own "New worktree HEAD is now at ..." line instead,
>   while keeping the progress indicator for larger repositories.

As with Junio, I'm fine with this hidden option (for now), however, I think you can take this a step further. Rather than having a (hidden) git-reset option which suppresses "HEAD is now at...", instead have a (hidden) option which augments the message. For example, --new-head-desc="New worktree" would make it output "New worktree HEAD is now at...". Changes to builtin/reset.c to support this would hardly be larger than the changes you already made.

The major benefit is that patch 3/6 no longer has to duplicate the code from builtin/reset.c:print_new_head_line() just to print its own "New worktree HEAD is now at..." message. (As for the argument that "git worktree add" must duplicate that code because it wants the message on stderr, whereas git-reset prints it to stdout, I don't see why git-worktree puts those messages to stderr in the first place. As far as I can tell, it would be equally valid to print them to stdout.)

Show 25 quoted lines
> Some examples of the new UI behaviour here for reference:
>
>  - guess-remote mode
>
>     $ git worktree add --guess-remote ../next
>     Creating branch 'next'
>     Branch 'next' set up to track remote branch 'next' from 'origin'.
>     New worktree HEAD is now at caa68db14 Merge branch 'sb/packfiles-in-repository' into next
>
>  - original dwim (create a branch based on the current HEAD)
>
>     $ git worktree add ../test
>     Creating branch 'test'
>     New worktree HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
>
>  - new dwim (check out existing branch)
>
>     $ git worktree add ../test
>     Checking out branch 'test'
>     New worktree HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
>
>  - no new branch created
>
>     $ git worktree add ../test2 origin/master
>     New worktree HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'

I like the "creating" or "checking out" messages we now get for all the DWIM cases. I wonder if it would make sense to print "Checkout out blah..." for this case too. It's certainly not necessary since the user specified <commit-ish> explicitly, but it would make the UI even more consistent, and address your subsequent comment about missing context above the "Checking out files: ...%" line for this case. Thoughts?

> Compare this to the old UI (new dwim omitted, as there's no old
> version of that):

Thanks for contrasting the new with the old. The new output is nicer and more helpful.

> The one thing we are loosing is a context line before "Checking out
> files:", if no new branch is created.  Personally I feel like that's
> acceptable, as the user just used the 'git worktree add' command, so
> it should be intuitive where those files are being checked out.
Thomas Gummerer· Apr 8, 2018, 14:24 UTC · re: Eric Sunshine · lore

Re: [PATCH v6 0/6] worktree: teach "add" to check out existing branches

On 04/08, Eric Sunshine wrote:
Show 25 quoted lines
> On Sat, Mar 31, 2018 at 11:17 AM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
> > This round should fix all the UI issues Eric found in the last round.
> > The changes I made in a bit more detail:
> >
> > - added a new commit introducing a new hidden --show-new-head-line
> >   flag in 'git reset'.  This is used to suppress the "HEAD is now at
> >   ..."  line that 'git reset --hard' usually prints, so we can replace
> >   it with our own "New worktree HEAD is now at ..." line instead,
> >   while keeping the progress indicator for larger repositories.
> 
> As with Junio, I'm fine with this hidden option (for now), however, I
> think you can take this a step further. Rather than having a (hidden)
> git-reset option which suppresses "HEAD is now at...", instead have a
> (hidden) option which augments the message. For example,
> --new-head-desc="New worktree" would make it output "New worktree HEAD
> is now at...". Changes to builtin/reset.c to support this would hardly
> be larger than the changes you already made.
> 
> The major benefit is that patch 3/6 no longer has to duplicate the
> code from builtin/reset.c:print_new_head_line() just to print its own
> "New worktree HEAD is now at..." message. (As for the argument that
> "git worktree add" must duplicate that code because it wants the
> message on stderr, whereas git-reset prints it to stdout, I don't see
> why git-worktree puts those messages to stderr in the first place. As
> far as I can tell, it would be equally valid to print them to stdout.)

I didn't think of that, but I think that's nicer indeed. Will change. This will also be nicer when we're in a position to remove the hidden option and do all of this with internal functions. Then we can just re-use the new function that also takes a prefix at that point (after moving the function to 'libgit.a' of course.

Show 33 quoted lines
> > Some examples of the new UI behaviour here for reference:
> >
> >  - guess-remote mode
> >
> >     $ git worktree add --guess-remote ../next
> >     Creating branch 'next'
> >     Branch 'next' set up to track remote branch 'next' from 'origin'.
> >     New worktree HEAD is now at caa68db14 Merge branch 'sb/packfiles-in-repository' into next
> >
> >  - original dwim (create a branch based on the current HEAD)
> >
> >     $ git worktree add ../test
> >     Creating branch 'test'
> >     New worktree HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
> >
> >  - new dwim (check out existing branch)
> >
> >     $ git worktree add ../test
> >     Checking out branch 'test'
> >     New worktree HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
> >
> >  - no new branch created
> >
> >     $ git worktree add ../test2 origin/master
> >     New worktree HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
> 
> I like the "creating" or "checking out" messages we now get for all
> the DWIM cases. I wonder if it would make sense to print "Checkout out
> blah..." for this case too. It's certainly not necessary since the
> user specified <commit-ish> explicitly, but it would make the UI even
> more consistent, and address your subsequent comment about missing
> context above the "Checking out files: ...%" line for this case.
> Thoughts?

Let me think through some of the cases here, of 'git worktre add <path> <commit-ish>' with various flags and what the UI would be with that added:

  - no flags:
    $ git worktree add ../test origin/master
    Checking out 'origin/master'
    Checking out files: ...%
    New worktree HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
  - -b branch:
    $ git worktree add -b test ../test origin/master
    Creating branch 'test'
    Checking out 'origin/master'
    Checking out files: ...%
    New worktree HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
    Would we want to omit the "Checking out ..." here?  I'm leaning
    towards yes, but dunno?
  - --no-checkout
    $ git worktree add --no-checkout test ../test origin/master
    New worktree HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
  - Original dwim with --detach flag
    $ git worktree add --detach ../test
    Checking out 'c2a499e6c'
    Checking out files: ...%
    New worktree HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'

Looking at this, I'm not sure what's best here. I'm not sure I'm a fan of the duplicate "Checking out " message (I assume that's what you meant above, or did you mean just "Checkout ..."?)

I als don't think it gives too much context compared to just "Checking out files: ...%". I think it gives a bit more context when that message is not displayed at all, as it shows whether files are checked out or not, but if we do that, when we create a new branch, the amount of output we'd display is getting a bit long, to the point where I suspect users would just not read it anymore.

So I personally don't feel like this is worth it, even though it may give some context in some cases. But I'm also far from an expert in UI design, so if you (or others) feel this would be nicer I'm happy to implement it :)

Show 10 quoted lines
> > Compare this to the old UI (new dwim omitted, as there's no old
> > version of that):
> 
> Thanks for contrasting the new with the old. The new output is nicer
> and more helpful.
> 
> > The one thing we are loosing is a context line before "Checking out
> > files:", if no new branch is created.  Personally I feel like that's
> > acceptable, as the user just used the 'git worktree add' command, so
> > it should be intuitive where those files are being checked out.
Eric Sunshine· Apr 9, 2018, 00:38 UTC · re: Thomas Gummerer · lore

Re: [PATCH v6 0/6] worktree: teach "add" to check out existing branches

On Sun, Apr 8, 2018 at 10:24 AM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
Show 18 quoted lines
> On 04/08, Eric Sunshine wrote:
>> On Sat, Mar 31, 2018 at 11:17 AM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
> Let me think through some of the cases here, of 'git worktre add
> <path> <commit-ish>' with various flags and what the UI would be with
> that added:
>
>   - no flags:
>
>     $ git worktree add ../test origin/master
>     Checking out 'origin/master'
>     Checking out files: ...%
>     New worktree HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
>
>   - -b branch:
>
>     $ git worktree add -b test ../test origin/master
>     Creating branch 'test'
>     Checking out 'origin/master'
Did you mean "Checking out 'test'"?
Show 5 quoted lines
>     Checking out files: ...%
>     New worktree HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
>
>     Would we want to omit the "Checking out ..." here?  I'm leaning
>     towards yes, but dunno?

To which "Checking out" message do you refer, the one showing the branch name or the one showing the checkout progress?

I'd probably agree that showing both "Creating" and "Checkout out" is overkill. However, see my response[1] to your "fixup!" patch in which I explore the idea that unifying "Checking out 'branch' and "Creating branch" messages may be a good idea and get us out of some UI jams which seem to be cropping up.

[1]: https://public-inbox.org/git/20180325134947.25828-1-t.gummerer@gmail.com/T/#m5d38b0c6427609e8c36aa6af83d518791c1e1581
Show 10 quoted lines
>   - Original dwim with --detach flag
>
>     $ git worktree add --detach ../test
>     Checking out 'c2a499e6c'
>     Checking out files: ...%
>     New worktree HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
>
> Looking at this, I'm not sure what's best here.  I'm not sure I'm a
> fan of the duplicate "Checking out " message (I assume that's what you
> meant above, or did you mean just "Checkout ..."?)
Taking [1] into account, this might become something like:
    $ git worktree add --detach ../test
    Preparing worktree (detached HEAD c2a499e6c)
    Checking out files: ...%
    New worktree HEAD is now at c2a499e6c Gobbledygook
Show 9 quoted lines
> I als don't think it gives too much context compared to just "Checking
> out files: ...%".  I think it gives a bit more context when that
> message is not displayed at all, as it shows whether files are checked
> out or not, but if we do that, when we create a new branch, the amount
> of output we'd display is getting a bit long, to the point where I
> suspect users would just not read it anymore.
>
> So I personally don't feel like this is worth it, even though it may
> give some context in some cases.

Fair enough observation. The idea suggested in [1] may keep output to a reasonable amount.

Thomas Gummerer· Apr 9, 2018, 19:47 UTC · re: Eric Sunshine · lore

Re: [PATCH v6 0/6] worktree: teach "add" to check out existing branches

On 04/08, Eric Sunshine wrote:
Show 56 quoted lines
> On Sun, Apr 8, 2018 at 10:24 AM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
> > On 04/08, Eric Sunshine wrote:
> >> On Sat, Mar 31, 2018 at 11:17 AM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
> > Let me think through some of the cases here, of 'git worktre add
> > <path> <commit-ish>' with various flags and what the UI would be with
> > that added:
> >
> >   - no flags:
> >
> >     $ git worktree add ../test origin/master
> >     Checking out 'origin/master'
> >     Checking out files: ...%
> >     New worktree HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
> >
> >   - -b branch:
> >
> >     $ git worktree add -b test ../test origin/master
> >     Creating branch 'test'
> >     Checking out 'origin/master'
> 
> Did you mean "Checking out 'test'"?
> 
> >     Checking out files: ...%
> >     New worktree HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
> >
> >     Would we want to omit the "Checking out ..." here?  I'm leaning
> >     towards yes, but dunno?
> 
> To which "Checking out" message do you refer, the one showing the
> branch name or the one showing the checkout progress?
> 
> I'd probably agree that showing both "Creating" and "Checkout out" is
> overkill. However, see my response[1] to your "fixup!" patch in which
> I explore the idea that unifying "Checking out 'branch' and "Creating
> branch" messages may be a good idea and get us out of some UI jams
> which seem to be cropping up.
> 
> [1]: https://public-inbox.org/git/20180325134947.25828-1-t.gummerer@gmail.com/T/#m5d38b0c6427609e8c36aa6af83d518791c1e1581
> 
> >   - Original dwim with --detach flag
> >
> >     $ git worktree add --detach ../test
> >     Checking out 'c2a499e6c'
> >     Checking out files: ...%
> >     New worktree HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
> >
> > Looking at this, I'm not sure what's best here.  I'm not sure I'm a
> > fan of the duplicate "Checking out " message (I assume that's what you
> > meant above, or did you mean just "Checkout ..."?)
> 
> Taking [1] into account, this might become something like:
> 
>     $ git worktree add --detach ../test
>     Preparing worktree (detached HEAD c2a499e6c)
>     Checking out files: ...%
>     New worktree HEAD is now at c2a499e6c Gobbledygook

The more I look at this solution, the more I like it. I'll try to implement this to see if there's anything I'm not thinking of right now, but I think I'll take the suggestion and send a re-roll with it implemented.

Show 12 quoted lines
> > I als don't think it gives too much context compared to just "Checking
> > out files: ...%".  I think it gives a bit more context when that
> > message is not displayed at all, as it shows whether files are checked
> > out or not, but if we do that, when we create a new branch, the amount
> > of output we'd display is getting a bit long, to the point where I
> > suspect users would just not read it anymore.
> >
> > So I personally don't feel like this is worth it, even though it may
> > give some context in some cases.
> 
> Fair enough observation. The idea suggested in [1] may keep output to
> a reasonable amount.
Thomas Gummerer· Apr 9, 2018, 19:30 UTC · re: Eric Sunshine · lore

Re: [PATCH v6 0/6] worktree: teach "add" to check out existing branches

On 04/08, Eric Sunshine wrote:
Show 17 quoted lines
> On Sat, Mar 31, 2018 at 11:17 AM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
> > This round should fix all the UI issues Eric found in the last round.
> > The changes I made in a bit more detail:
> >
> > - added a new commit introducing a new hidden --show-new-head-line
> >   flag in 'git reset'.  This is used to suppress the "HEAD is now at
> >   ..."  line that 'git reset --hard' usually prints, so we can replace
> >   it with our own "New worktree HEAD is now at ..." line instead,
> >   while keeping the progress indicator for larger repositories.
> 
> As with Junio, I'm fine with this hidden option (for now), however, I
> think you can take this a step further. Rather than having a (hidden)
> git-reset option which suppresses "HEAD is now at...", instead have a
> (hidden) option which augments the message. For example,
> --new-head-desc="New worktree" would make it output "New worktree HEAD
> is now at...". Changes to builtin/reset.c to support this would hardly
> be larger than the changes you already made.

Something else I just noticed that may make this a worse solution is that this breaks the sentence in two pieces for translators. I guess we could somehow get the "New worktree" part of the option translated, but that still means that if some language would require to move parts of the sentence around that would be less than ideal for translation.

Duy pointed this out to me in an earlier patch series, and I think we should probably not make life harder (or impossible) for translators if we can avoid it.

Would factoring out what we have in 'print_new_head_line()' into some common code, maybe in 'pretty.c', and still doing the printing from here be a reasonable tradeoff?

I think this could potentially even be re-used in other places, although again I'd like to keep that for a followup series to avoid scope creep in this one.

Show 52 quoted lines
> The major benefit is that patch 3/6 no longer has to duplicate the
> code from builtin/reset.c:print_new_head_line() just to print its own
> "New worktree HEAD is now at..." message. (As for the argument that
> "git worktree add" must duplicate that code because it wants the
> message on stderr, whereas git-reset prints it to stdout, I don't see
> why git-worktree puts those messages to stderr in the first place. As
> far as I can tell, it would be equally valid to print them to stdout.)
> 
> > Some examples of the new UI behaviour here for reference:
> >
> >  - guess-remote mode
> >
> >     $ git worktree add --guess-remote ../next
> >     Creating branch 'next'
> >     Branch 'next' set up to track remote branch 'next' from 'origin'.
> >     New worktree HEAD is now at caa68db14 Merge branch 'sb/packfiles-in-repository' into next
> >
> >  - original dwim (create a branch based on the current HEAD)
> >
> >     $ git worktree add ../test
> >     Creating branch 'test'
> >     New worktree HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
> >
> >  - new dwim (check out existing branch)
> >
> >     $ git worktree add ../test
> >     Checking out branch 'test'
> >     New worktree HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
> >
> >  - no new branch created
> >
> >     $ git worktree add ../test2 origin/master
> >     New worktree HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
> 
> I like the "creating" or "checking out" messages we now get for all
> the DWIM cases. I wonder if it would make sense to print "Checkout out
> blah..." for this case too. It's certainly not necessary since the
> user specified <commit-ish> explicitly, but it would make the UI even
> more consistent, and address your subsequent comment about missing
> context above the "Checking out files: ...%" line for this case.
> Thoughts?
> 
> > Compare this to the old UI (new dwim omitted, as there's no old
> > version of that):
> 
> Thanks for contrasting the new with the old. The new output is nicer
> and more helpful.
> 
> > The one thing we are loosing is a context line before "Checking out
> > files:", if no new branch is created.  Personally I feel like that's
> > acceptable, as the user just used the 'git worktree add' command, so
> > it should be intuitive where those files are being checked out.
Eric Sunshine· Apr 9, 2018, 22:06 UTC · re: Thomas Gummerer · lore

Re: [PATCH v6 0/6] worktree: teach "add" to check out existing branches

On Mon, Apr 9, 2018 at 3:30 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
Show 14 quoted lines
> On 04/08, Eric Sunshine wrote:
>> As with Junio, I'm fine with this hidden option (for now), however, I
>> think you can take this a step further. Rather than having a (hidden)
>> git-reset option which suppresses "HEAD is now at...", instead have a
>> (hidden) option which augments the message. For example,
>> --new-head-desc="New worktree" would make it output "New worktree HEAD
>> is now at...". Changes to builtin/reset.c to support this would hardly
>> be larger than the changes you already made.
>
> Something else I just noticed that may make this a worse solution is
> that this breaks the sentence in two pieces for translators.  I guess
> we could somehow get the "New worktree" part of the option translated,
> but that still means that if some language would require to move parts
> of the sentence around that would be less than ideal for translation.
Good point.

One solution would be to have the new hidden option replace the string entirely: --new-head-msg="New worktree HEAD is now at %s", which would allow translators to deal with the entire sentence. Even clearer would be to drop "now", as in "New worktree HEAD is at %s". (Default in reset.c would still be "HEAD is now at %s", of course.)

Another solution would be not to augment the "HEAD is now at..." message at all. I realize that that augmentation was one of the original motivations for this patch series, but with the upcoming restoration of the "Preparing worktree" message:

    Preparing worktree (_branch disposition_)
    HEAD is now at ...

it seems clear enough (at least to me) from the context introduced by the "Preparing..." message that "HEAD is now at..." refers to HEAD in the worktree. (But that's just my opinion.)

> Would factoring out what we have in 'print_new_head_line()' into some
> common code, maybe in 'pretty.c', and still doing the printing from
> here be a reasonable tradeoff?

Isn't that getting uglier again? Not only would you have to publish that function, but you'd still need the hidden git-reset --show-new-head-line option.

Also, you'd end up calling that function from within low-level worker worktree.c:add_worktree(), thus making it take on UI duties, which would be nice to avoid if possible. (Unfortunately, the alternate idea of having worktree.c:add() handle this UI task doesn't quite work since add_worktree() doesn't return sufficient information for add() to know whether or not it should print "HEAD is now at..."; however, add_worktree() could be augmented to return more information.)

So, I don't presently have a good answer. I'm partial to the idea of not augmenting "HEAD is now at...", partly because context makes it relatively clear that it applies to the new worktree and partly because it's simpler (less implementation work for you) to leave it as is. If that choice isn't desirable, then next best would be for --new-head-msg= to replace the entire "HEAD is now at..." string rather than augmenting it.

Thomas Gummerer· Apr 11, 2018, 20:09 UTC · re: Eric Sunshine · lore

Re: [PATCH v6 0/6] worktree: teach "add" to check out existing branches

On 04/09, Eric Sunshine wrote:
Show 28 quoted lines
> On Mon, Apr 9, 2018 at 3:30 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
> > On 04/08, Eric Sunshine wrote:
> >> As with Junio, I'm fine with this hidden option (for now), however, I
> >> think you can take this a step further. Rather than having a (hidden)
> >> git-reset option which suppresses "HEAD is now at...", instead have a
> >> (hidden) option which augments the message. For example,
> >> --new-head-desc="New worktree" would make it output "New worktree HEAD
> >> is now at...". Changes to builtin/reset.c to support this would hardly
> >> be larger than the changes you already made.
> >
> > Something else I just noticed that may make this a worse solution is
> > that this breaks the sentence in two pieces for translators.  I guess
> > we could somehow get the "New worktree" part of the option translated,
> > but that still means that if some language would require to move parts
> > of the sentence around that would be less than ideal for translation.
> 
> Good point.
> 
> One solution would be to have the new hidden option replace the string
> entirely: --new-head-msg="New worktree HEAD is now at %s", which would
> allow translators to deal with the entire sentence. Even clearer would
> be to drop "now", as in "New worktree HEAD is at %s". (Default in
> reset.c would still be "HEAD is now at %s", of course.)
> 
> Another solution would be not to augment the "HEAD is now at..."
> message at all. I realize that that augmentation was one of the
> original motivations for this patch series, but with the upcoming
> restoration of the "Preparing worktree" message:

My original motivation of the series was to just make the new dwim work :) Because that's adding some magic, the secondary motivation became improving the UI, to help users see which dwim was used. I felt like this was going to be one of those improvements, especially after we get rid of the "Preparing ..." line.

I do however like your suggestion of the "Preparing worktree (_branch disposition_)", as that doesn't add more lines to the output, while still giving a good indication of what exactly is happening. At that point just showing "HEAD is now at ..." is fine by me, and doesn't require adding the hidden flag to 'git reset'. So I'm happy just dropping the change in the message here, which will simplify things.

Thanks for the suggestion!
Show 30 quoted lines
>     Preparing worktree (_branch disposition_)
>     HEAD is now at ...
> 
> it seems clear enough (at least to me) from the context introduced by
> the "Preparing..." message that "HEAD is now at..." refers to HEAD in
> the worktree. (But that's just my opinion.)
> 
> > Would factoring out what we have in 'print_new_head_line()' into some
> > common code, maybe in 'pretty.c', and still doing the printing from
> > here be a reasonable tradeoff?
> 
> Isn't that getting uglier again? Not only would you have to publish
> that function, but you'd still need the hidden git-reset
> --show-new-head-line option.
> 
> Also, you'd end up calling that function from within low-level worker
> worktree.c:add_worktree(), thus making it take on UI duties, which
> would be nice to avoid if possible. (Unfortunately, the alternate idea
> of having worktree.c:add() handle this UI task doesn't quite work
> since add_worktree() doesn't return sufficient information for add()
> to know whether or not it should print "HEAD is now at..."; however,
> add_worktree() could be augmented to return more information.)
> 
> So, I don't presently have a good answer. I'm partial to the idea of
> not augmenting "HEAD is now at...", partly because context makes it
> relatively clear that it applies to the new worktree and partly
> because it's simpler (less implementation work for you) to leave it as
> is. If that choice isn't desirable, then next best would be for
> --new-head-msg= to replace the entire "HEAD is now at..." string
> rather than augmenting it.
Eric Sunshine· Apr 11, 2018, 20:48 UTC · re: Thomas Gummerer · lore

Re: [PATCH v6 0/6] worktree: teach "add" to check out existing branches

On Wed, Apr 11, 2018 at 4:09 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
Show 18 quoted lines
> On 04/09, Eric Sunshine wrote:
>> Another solution would be not to augment the "HEAD is now at..."
>> message at all. I realize that that augmentation was one of the
>> original motivations for this patch series, but with the upcoming
>> restoration of the "Preparing worktree" message:
>
> My original motivation of the series was to just make the new dwim
> work :)  Because that's adding some magic, the secondary motivation
> became improving the UI, to help users see which dwim was used.  I
> felt like this was going to be one of those improvements, especially
> after we get rid of the "Preparing ..." line.
>
> I do however like your suggestion of the "Preparing worktree (_branch
> disposition_)", as that doesn't add more lines to the output, while
> still giving a good indication of what exactly is happening.  At that
> point just showing "HEAD is now at ..." is fine by me, and doesn't
> require adding the hidden flag to 'git reset'.  So I'm happy just
> dropping the change in the message here, which will simplify things.
Nice. This sounds like a good plan for moving forward.
Thomas Gummerer· Apr 11, 2018, 20:50 UTC · re: Thomas Gummerer · lore

Re: [PATCH v6 0/6] worktree: teach "add" to check out existing branches

On 04/11, Thomas Gummerer wrote:
Show 42 quoted lines
> On 04/09, Eric Sunshine wrote:
> > On Mon, Apr 9, 2018 at 3:30 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
> > > On 04/08, Eric Sunshine wrote:
> > >> As with Junio, I'm fine with this hidden option (for now), however, I
> > >> think you can take this a step further. Rather than having a (hidden)
> > >> git-reset option which suppresses "HEAD is now at...", instead have a
> > >> (hidden) option which augments the message. For example,
> > >> --new-head-desc="New worktree" would make it output "New worktree HEAD
> > >> is now at...". Changes to builtin/reset.c to support this would hardly
> > >> be larger than the changes you already made.
> > >
> > > Something else I just noticed that may make this a worse solution is
> > > that this breaks the sentence in two pieces for translators.  I guess
> > > we could somehow get the "New worktree" part of the option translated,
> > > but that still means that if some language would require to move parts
> > > of the sentence around that would be less than ideal for translation.
> > 
> > Good point.
> > 
> > One solution would be to have the new hidden option replace the string
> > entirely: --new-head-msg="New worktree HEAD is now at %s", which would
> > allow translators to deal with the entire sentence. Even clearer would
> > be to drop "now", as in "New worktree HEAD is at %s". (Default in
> > reset.c would still be "HEAD is now at %s", of course.)
> > 
> > Another solution would be not to augment the "HEAD is now at..."
> > message at all. I realize that that augmentation was one of the
> > original motivations for this patch series, but with the upcoming
> > restoration of the "Preparing worktree" message:
> 
> My original motivation of the series was to just make the new dwim
> work :)  Because that's adding some magic, the secondary motivation
> became improving the UI, to help users see which dwim was used.  I
> felt like this was going to be one of those improvements, especially
> after we get rid of the "Preparing ..." line.
> 
> I do however like your suggestion of the "Preparing worktree (_branch
> disposition_)", as that doesn't add more lines to the output, while
> still giving a good indication of what exactly is happening.  At that
> point just showing "HEAD is now at ..." is fine by me, and doesn't
> require adding the hidden flag to 'git reset'.  So I'm happy just
> dropping the change in the message here, which will simplify things.

And just as I'm re-reading my commit messages, I guess there was one more motivation for printing the "HEAD is now at ..." line ourselves:

    If the '--no-checkout' flag is given, the output of 'git worktree add'
    is just:
    
        Preparing foo (identifier foo)
    
    even though the HEAD is set to a commit, which is just not checked out.

I think I can live with that for now, I personally don't use '--no-checkout', and we could fix this at some point in the future if we desire to do so. I think we can consider that out of scope for this patch series, as its main goal is to introduce the new dwim.

> Thanks for the suggestion!
Eric Sunshine· Apr 11, 2018, 21:14 UTC · re: Thomas Gummerer · lore

Re: [PATCH v6 0/6] worktree: teach "add" to check out existing branches

On Wed, Apr 11, 2018 at 4:50 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
Show 14 quoted lines
> And just as I'm re-reading my commit messages, I guess there was one
> more motivation for printing the "HEAD is now at ..." line ourselves:
>
>     If the '--no-checkout' flag is given, the output of 'git worktree add'
>     is just:
>
>         Preparing foo (identifier foo)
>
>     even though the HEAD is set to a commit, which is just not checked out.
>
> I think I can live with that for now, I personally don't use
> '--no-checkout', and we could fix this at some point in the future if
> we desire to do so.  I think we can consider that out of scope for
> this patch series, as its main goal is to introduce the new dwim.

Sounds reasonable, especially since the proposed "Preparing worktree (_branch description_)" provides similarly useful feedback.

Thomas Gummerer· Apr 15, 2018, 20:29 UTC · re: Thomas Gummerer · lore

[PATCH v7 0/4] worktree: teach "add" to check out existing branches

Thanks Eric for the review and all of the suggestions in the last round.

Previous rounds are at <20180121120208.12760-1-t.gummerer@gmail.com>, <20180204221305.28300-1-t.gummerer@gmail.com>, <20180317220830.30963-1-t.gummerer@gmail.com>, <20180317222219.4940-1-t.gummerer@gmail.com>, <20180325134947.25828-1-t.gummerer@gmail.com> and <20180331151804.30380-1-t.gummerer@gmail.com>.

The main change once again in this series is the user interface. It feels like we went in a complete circle here now, as this iteration is bringing the "Preparing ..." line back (although in a slightly different form than the original), and is moving away from printing it's own "HEAD is now at..." line again. This also means we don't need the new hidden option to 'git reset' anymore, which is nice.

I do like the new UI more than what we had in the last round (which I already liked more than the original UI) :)

Other than those changes, it also includes Eric's suggestion for a better wording in the documentation, fixes the argument order to test_cmd_rev in a test, and makes a test more robust.

To demonstrate the UI updates, let's compare the new UI and the old UI again. This is the same commands as used for the demonstration in the last iteration, so please have a look at <20180331151804.30380-1-t.gummerer@gmail.com> for an example of what it looked like after the last round.

New UI:
 - guess-remote mode
    $ git worktree add --guess-remote ../next
    Preparing worktree (new branch 'next')
    Branch 'next' set up to track remote branch 'next' from 'origin'.
    HEAD is now at caa68db14 Merge branch 'sb/packfiles-in-repository' into next
 - original dwim (create a branch based on the current HEAD)
    $ git worktree add ../test
    Preparing worktree (new branch 'test')
    HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
 - new dwim (check out existing branch)
    $ git worktree add ../test
    Preparing worktree (checking out 'test')
    HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
 - detached HEAD
    $ git worktree add ../test2 origin/master
    Preparing worktree (detached HEAD c2a499e6c)
    HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
 - resetting existing branch
    $ git worktree add -B next ../test3 origin/master
    Preparing worktree (resetting branch 'next' (was at caa68db14))
    Branch 'next' set up to track remote branch 'master' from 'origin'.
    HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
    This output is new in this round and wasn't previously discussed.
    While working on the "Preparing ..." line I noticed this, and
    thought it would be a good idea.  I feel like this fits in the
    scope of the series quite well, as it's improving the UI, but I'm
    happy to split it out if that's preferred.
    It may also be worth displaying the title of the commit here, but
    at that point the line would get a bit long, so dunno.
 - large repository (with original dwim)
    $ git worktree add ../test
    Preparing worktree (new branch 'test')
    Checking out files: 100% (62915/62915), done.
    HEAD is now at c2a9838452a4 Merge tag 'for-4.16/dm-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
 - error when directory already exists
    $ git worktree add ../test
    Preparing worktree (checking out 'test')
    fatal: '../test' already exists

Compare this to the old UI (new dwim omitted, as there's no old version of that):

 - guess-remote mode
    $ git worktree add --guess-remote ../next
    Branch 'next' set up to track remote branch 'next' from 'origin'.
    Preparing ../next (identifier next)
    HEAD is now at caa68db14 Merge branch 'sb/packfiles-in-repository' into next
 - original dwim (create a branch based on the current HEAD)
    $ git worktree add ../test
    Preparing ../test (identifier test)
    HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
 - no new branch created
    $ git worktree add ../test2 origin/master
    Preparing ../test2 (identifier test2)
    HEAD is now at c2a499e6c Merge branch 'jh/partial-clone'
 - large repository
    $ git worktree add ../test
    Preparing ../test (identifier test)
    Checking out files: 100% (62915/62915), done.
    HEAD is now at c2a9838452a4 Merge tag 'for-4.16/dm-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
 - error when directory already exists
    $ git worktree add ../test
    fatal: '../test' already exists
Interdiff below:
Show changes to 5 files +42 −32

Documentation/git-worktree.txt, builtin/reset.c, builtin/worktree.c, t/t2025-worktree-add.sh, t/t7102-reset.sh

diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index eaa6bf713f..5d54f36a71 100644
--- a/Documentation/git-worktree.txt
+++ b/Documentation/git-worktree.txt
@@ -61,13 +61,13 @@ $ git worktree add --track -b <branch> <path> <remote>/<branch>
 ------------
 +
 If `<commit-ish>` is omitted and neither `-b` nor `-B` nor `--detach` used,
-then, as a convenience, a worktree with a branch named after
-`$(basename <path>)` (call it `<branch>`) is created.  If `<branch>`
+then, as a convenience, the new worktree is associated with a branch
+(call it `<branch>`) named after `$(basename <path>)`.  If `<branch>`
 doesn't exist, a new branch based on HEAD is automatically created as
-if `-b <branch>` was given.  If `<branch>` exists in the repository,
-it will be checked out in the new worktree, if it's not checked out
-anywhere else, otherwise the command will refuse to create the
-worktree (unless `--force` is used).
+if `-b <branch>` was given.  If `<branch>` does exist, it will be
+checked out in the new worktree, if it's not checked out anywhere
+else, otherwise the command will refuse to create the worktree (unless
+`--force` is used).
 
 list::
 
diff --git a/builtin/reset.c b/builtin/reset.c
index 54b2576449..e15f595799 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -288,7 +288,6 @@ static int git_reset_config(const char *var, const char *value, void *cb)
 int cmd_reset(int argc, const char **argv, const char *prefix)
 {
 	int reset_type = NONE, update_ref_status = 0, quiet = 0;
-	int show_new_head_line = 1;
 	int patch_mode = 0, unborn;
 	const char *rev;
 	struct object_id oid;
@@ -311,7 +310,6 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
 		OPT_BOOL('p', "patch", &patch_mode, N_("select hunks interactively")),
 		OPT_BOOL('N', "intent-to-add", &intent_to_add,
 				N_("record only the fact that removed paths will be added later")),
-		OPT_HIDDEN_BOOL(0, "show-new-head-line", &show_new_head_line, N_("show information on the new HEAD")),
 		OPT_END()
 	};
 
@@ -405,8 +403,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
 		 * switched to, saving the previous head in ORIG_HEAD before. */
 		update_ref_status = reset_refs(rev, &oid);
 
-		if (reset_type == HARD && !update_ref_status && !quiet &&
-		    show_new_head_line)
+		if (reset_type == HARD && !update_ref_status && !quiet)
 			print_new_head_line(lookup_commit_reference(&oid));
 	}
 	if (!pathspec.nr)
diff --git a/builtin/worktree.c b/builtin/worktree.c
index ccc2e63e0f..f5a5283b39 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -27,7 +27,6 @@ struct add_opts {
 	int detach;
 	int checkout;
 	int keep_locked;
-	int checkout_existing_branch;
 };
 
 static int show_only;
@@ -317,28 +316,16 @@ static int add_worktree(const char *path, const char *refname,
 	if (ret)
 		goto done;
 
-	if (opts->checkout_existing_branch)
-		  fprintf_ln(stderr, _("Checking out branch '%s'"), refname);
 	if (opts->checkout) {
 		cp.argv = NULL;
 		argv_array_clear(&cp.args);
 		argv_array_pushl(&cp.args, "reset", "--hard", NULL);
-		argv_array_push(&cp.args, "--no-show-new-head-line");
 		cp.env = child_env.argv;
 		ret = run_command(&cp);
 		if (ret)
 			goto done;
 	}
 
-	fprintf(stderr, _("New worktree HEAD is now at %s"),
-		find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
-
-	strbuf_reset(&sb);
-	pp_commit_easy(CMIT_FMT_ONELINE, commit, &sb);
-	if (sb.len > 0)
-		fprintf(stderr, " %s", sb.buf);
-	fputc('\n', stderr);
-
 	is_junk = 0;
 	FREE_AND_NULL(junk_work_tree);
 	FREE_AND_NULL(junk_git_dir);
@@ -366,6 +353,34 @@ static int add_worktree(const char *path, const char *refname,
 	return ret;
 }
 
+static void print_preparing_worktree_line(const char *branch,
+					  const char *new_branch,
+					  const char *new_branch_force,
+					  int checkout_existing_branch)
+{
+	if (checkout_existing_branch) {
+		printf_ln(_("Preparing worktree (checking out '%s')"), branch);
+	} else if (new_branch_force) {
+		struct commit *commit = lookup_commit_reference_by_name(new_branch_force);
+		if (!commit)
+			printf_ln(_("Preparing worktree (new branch '%s')"), new_branch_force);
+		else
+			printf_ln(_("Preparing worktree (resetting branch '%s' (was at %s))"),
+				  new_branch_force,
+				  find_unique_abbrev(commit->object.oid.hash,
+						     DEFAULT_ABBREV));
+	} else if (new_branch) {
+		printf_ln(_("Preparing worktree (new branch '%s')"), new_branch);
+	} else {
+		struct commit *commit = lookup_commit_reference_by_name(branch);
+		if (!commit)
+			die(_("invalid reference: %s"), branch);
+		printf_ln(_("Preparing worktree (detached HEAD %s)"),
+			  find_unique_abbrev(commit->object.oid.hash,
+					     DEFAULT_ABBREV));
+	}
+}
+
 static const char *dwim_branch(const char *path, const char **new_branch,
 			       int *checkout_existing_branch)
 {
@@ -397,6 +412,7 @@ static int add(int ac, const char **av, const char *prefix)
 	struct add_opts opts;
 	const char *new_branch_force = NULL;
 	char *path;
+	int checkout_existing_branch = 0;
 	const char *branch;
 	const char *new_branch = NULL;
 	const char *opt_track = NULL;
@@ -445,7 +461,7 @@ static int add(int ac, const char **av, const char *prefix)
 
 	if (ac < 2 && !new_branch && !opts.detach) {
 		const char *s = dwim_branch(path, &new_branch,
-					    &opts.checkout_existing_branch);
+					    &checkout_existing_branch);
 		if (s)
 			branch = s;
 	}
@@ -465,10 +481,11 @@ static int add(int ac, const char **av, const char *prefix)
 		}
 	}
 
+	print_preparing_worktree_line(branch, new_branch, new_branch_force,
+				      checkout_existing_branch);
+
 	if (new_branch) {
 		struct child_process cp = CHILD_PROCESS_INIT;
-
-		fprintf_ln(stderr, _("Creating branch '%s'"), new_branch);
 		cp.git_cmd = 1;
 		argv_array_push(&cp.args, "branch");
 		if (new_branch_force)
diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
index f72cb0eb0b..ad38507d00 100755
--- a/t/t2025-worktree-add.sh
+++ b/t/t2025-worktree-add.sh
@@ -204,7 +204,7 @@ test_expect_success '"add" checks out existing branch of dwimd name' '
 	test_cmp_rev HEAD~1 dwim &&
 	(
 		cd dwim &&
-		test_cmp_rev dwim HEAD
+		test_cmp_rev HEAD dwim
 	)
 '
 
@@ -215,6 +215,7 @@ test_expect_success '"add <path>" dwim fails with checked out branch' '
 '
 
 test_expect_success '"add --force" with existing dwimd name doesnt die' '
+	git checkout test-branch &&
 	git worktree add --force test-branch
 '
 
diff --git a/t/t7102-reset.sh b/t/t7102-reset.sh
index a160f78aba..95653a08ca 100755
--- a/t/t7102-reset.sh
+++ b/t/t7102-reset.sh
@@ -568,9 +568,4 @@ test_expect_success 'reset --mixed sets up work tree' '
 	test_cmp expect actual
 '
 
-test_expect_success 'reset --no-show-new-head-line suppresses "HEAD is now at" output' '
-	git reset --hard --no-show-new-head-line HEAD >actual &&
-	! grep "HEAD is now at" <actual
-'
-
 test_done

Thomas Gummerer (4):
  worktree: remove extra members from struct add_opts
  worktree: improve message when creating a new worktree
  worktree: factor out dwim_branch function
  worktree: teach "add" to check out existing branches

 Documentation/git-worktree.txt |   9 +++-
 builtin/worktree.c             | 101 ++++++++++++++++++++++++++++++-----------
 t/t2025-worktree-add.sh        |  26 ++++++++---
 3 files changed, 100 insertions(+), 36 deletions(-)

-- 
2.16.1.74.g6cd9b6cbe3
Thomas Gummerer· Apr 15, 2018, 20:29 UTC · re: Thomas Gummerer · lore

[PATCH v7 1/4] worktree: remove extra members from struct add_opts

There are two members of 'struct add_opts', which are only used inside the 'add()' function, but being part of 'struct add_opts' they are needlessly also passed to the 'add_worktree' function.

Make them local to the 'add()' function to make it clearer where they are used.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 builtin/worktree.c | 32 +++++++++++++++-----------------
 1 file changed, 15 insertions(+), 17 deletions(-)
Show changes to builtin/worktree.c +15 −17
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 7cef5b120b..4d96a21a45 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -27,8 +27,6 @@ struct add_opts {
 	int detach;
 	int checkout;
 	int keep_locked;
-	const char *new_branch;
-	int force_new_branch;
 };
 
 static int show_only;
@@ -363,10 +361,11 @@ static int add(int ac, const char **av, const char *prefix)
 	const char *new_branch_force = NULL;
 	char *path;
 	const char *branch;
+	const char *new_branch = NULL;
 	const char *opt_track = NULL;
 	struct option options[] = {
 		OPT__FORCE(&opts.force, N_("checkout <branch> even if already checked out in other worktree")),
-		OPT_STRING('b', NULL, &opts.new_branch, N_("branch"),
+		OPT_STRING('b', NULL, &new_branch, N_("branch"),
 			   N_("create a new branch")),
 		OPT_STRING('B', NULL, &new_branch_force, N_("branch"),
 			   N_("create or reset a branch")),
@@ -384,7 +383,7 @@ static int add(int ac, const char **av, const char *prefix)
 	memset(&opts, 0, sizeof(opts));
 	opts.checkout = 1;
 	ac = parse_options(ac, av, prefix, options, worktree_usage, 0);
-	if (!!opts.detach + !!opts.new_branch + !!new_branch_force > 1)
+	if (!!opts.detach + !!new_branch + !!new_branch_force > 1)
 		die(_("-b, -B, and --detach are mutually exclusive"));
 	if (ac < 1 || ac > 2)
 		usage_with_options(worktree_usage, options);
@@ -395,33 +394,32 @@ static int add(int ac, const char **av, const char *prefix)
 	if (!strcmp(branch, "-"))
 		branch = "@{-1}";
 
-	opts.force_new_branch = !!new_branch_force;
-	if (opts.force_new_branch) {
+	if (new_branch_force) {
 		struct strbuf symref = STRBUF_INIT;
 
-		opts.new_branch = new_branch_force;
+		new_branch = new_branch_force;
 
 		if (!opts.force &&
-		    !strbuf_check_branch_ref(&symref, opts.new_branch) &&
+		    !strbuf_check_branch_ref(&symref, new_branch) &&
 		    ref_exists(symref.buf))
 			die_if_checked_out(symref.buf, 0);
 		strbuf_release(&symref);
 	}
 
-	if (ac < 2 && !opts.new_branch && !opts.detach) {
+	if (ac < 2 && !new_branch && !opts.detach) {
 		int n;
 		const char *s = worktree_basename(path, &n);
-		opts.new_branch = xstrndup(s, n);
+		new_branch = xstrndup(s, n);
 		if (guess_remote) {
 			struct object_id oid;
 			const char *remote =
-				unique_tracking_name(opts.new_branch, &oid);
+				unique_tracking_name(new_branch, &oid);
 			if (remote)
 				branch = remote;
 		}
 	}
 
-	if (ac == 2 && !opts.new_branch && !opts.detach) {
+	if (ac == 2 && !new_branch && !opts.detach) {
 		struct object_id oid;
 		struct commit *commit;
 		const char *remote;
@@ -430,25 +428,25 @@ static int add(int ac, const char **av, const char *prefix)
 		if (!commit) {
 			remote = unique_tracking_name(branch, &oid);
 			if (remote) {
-				opts.new_branch = branch;
+				new_branch = branch;
 				branch = remote;
 			}
 		}
 	}
 
-	if (opts.new_branch) {
+	if (new_branch) {
 		struct child_process cp = CHILD_PROCESS_INIT;
 		cp.git_cmd = 1;
 		argv_array_push(&cp.args, "branch");
-		if (opts.force_new_branch)
+		if (new_branch_force)
 			argv_array_push(&cp.args, "--force");
-		argv_array_push(&cp.args, opts.new_branch);
+		argv_array_push(&cp.args, new_branch);
 		argv_array_push(&cp.args, branch);
 		if (opt_track)
 			argv_array_push(&cp.args, opt_track);
 		if (run_command(&cp))
 			return -1;
-		branch = opts.new_branch;
+		branch = new_branch;
 	} else if (opt_track) {
 		die(_("--[no-]track can only be used if a new branch is created"));
 	}

-- 
2.17.0.252.gfe0a9eaf31
Thomas Gummerer· Apr 15, 2018, 20:29 UTC · re: Thomas Gummerer · lore

[PATCH v7 3/4] worktree: factor out dwim_branch function

Factor out a dwim_branch function, which takes care of the dwim'ery in 'git worktree add <path>'. It's not too much code currently, but we're adding a new kind of dwim in a subsequent patch, at which point it makes more sense to have it as a separate function.

Factor it out now to reduce the patch noise in the next patch.
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 builtin/worktree.c | 27 +++++++++++++++++----------
 1 file changed, 17 insertions(+), 10 deletions(-)
Show changes to builtin/worktree.c +17 −10
diff --git a/builtin/worktree.c b/builtin/worktree.c
index a2667d74fb..893139629a 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -378,6 +378,20 @@ static void print_preparing_worktree_line(const char *branch,
 	}
 }
 
+static const char *dwim_branch(const char *path, const char **new_branch)
+{
+	int n;
+	const char *s = worktree_basename(path, &n);
+	*new_branch = xstrndup(s, n);
+	if (guess_remote) {
+		struct object_id oid;
+		const char *remote =
+			unique_tracking_name(*new_branch, &oid);
+		return remote;
+	}
+	return NULL;
+}
+
 static int add(int ac, const char **av, const char *prefix)
 {
 	struct add_opts opts;
@@ -430,16 +444,9 @@ static int add(int ac, const char **av, const char *prefix)
 	}
 
 	if (ac < 2 && !new_branch && !opts.detach) {
-		int n;
-		const char *s = worktree_basename(path, &n);
-		new_branch = xstrndup(s, n);
-		if (guess_remote) {
-			struct object_id oid;
-			const char *remote =
-				unique_tracking_name(new_branch, &oid);
-			if (remote)
-				branch = remote;
-		}
+		const char *s = dwim_branch(path, &new_branch);
+		if (s)
+			branch = s;
 	}
 
 	if (ac == 2 && !new_branch && !opts.detach) {

-- 
2.17.0.252.gfe0a9eaf31
Thomas Gummerer· Apr 15, 2018, 20:29 UTC · re: Thomas Gummerer · lore

[PATCH v7 2/4] worktree: improve message when creating a new worktree

Currently 'git worktree add' produces output like the following:
    Preparing ../foo (identifier foo)
    HEAD is now at 26da330922 <title>

The '../foo' is the path where the worktree is created, which the user has just given on the command line. The identifier is an internal implementation detail, which is not particularly relevant for the user and indeed isn't mentioned explicitly anywhere in the man page.

Instead of this message, print a message that gives the user a bit more detail of what exactly 'git worktree' is doing. There are various dwim modes which are perform some magic under the hood, which should be helpful to users. Just from the output of the command it is not always visible to users what exactly has happened.

Help the users a bit more by modifying the "Preparing ..." message and adding some additional information of what 'git worktree add' did under the hood, while not displaying the identifier anymore.

Currently this ends up in three different cases:
  - 'git worktree add -b ...' or 'git worktree add <path>', both of
    which create a new branch, either through the user explicitly
    requesting it, or through 'git worktree add' implicitly creating
    it.  This will end up with the following output:
      Preparing worktree (new branch '<branch>')
      HEAD is now at 26da330922 <title>
  - 'git worktree add -B ...', which may either create a new branch if
    the branch with the given name does not exist yet, or resets an
    existing branch to the current HEAD, or the commit-ish given.
    Depending on which action is taken, we'll end up with the following
    output:
      Preparing worktree (resetting branch 'next' (was at caa68db14))
      HEAD is now at 26da330922 <title>
    or:
      Preparing worktree (new branch '<branch>')
      HEAD is now at 26da330922 <title>
  - 'git worktree add --detach' or 'git worktree add <path> <branch>',
    both of which create a new worktree with a detached HEAD, for which
    we will print the following output:
      Preparing worktree (detached HEAD 26da330922)
      HEAD is now at 26da330922 <title>

Additionally currently the "Preparing ..." line is printed to stderr, while the "HEAD is now at ..." line is printed to stdout by 'git reset --hard', which is used internally by 'git worktree add'. Fix this inconsistency by printing the "Preparing ..." message to stdout as well. As "Preparing ..." is not an error, stdout also seems like the more appropriate output stream.

Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 builtin/worktree.c | 29 +++++++++++++++++++++++++++--
 1 file changed, 27 insertions(+), 2 deletions(-)
Show changes to builtin/worktree.c +27 −2
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 4d96a21a45..a2667d74fb 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -301,8 +301,6 @@ static int add_worktree(const char *path, const char *refname,
 	strbuf_addf(&sb, "%s/commondir", sb_repo.buf);
 	write_file(sb.buf, "../..");
 
-	fprintf_ln(stderr, _("Preparing %s (identifier %s)"), path, name);
-
 	argv_array_pushf(&child_env, "%s=%s", GIT_DIR_ENVIRONMENT, sb_git.buf);
 	argv_array_pushf(&child_env, "%s=%s", GIT_WORK_TREE_ENVIRONMENT, path);
 	cp.git_cmd = 1;
@@ -355,6 +353,31 @@ static int add_worktree(const char *path, const char *refname,
 	return ret;
 }
 
+static void print_preparing_worktree_line(const char *branch,
+					  const char *new_branch,
+					  const char *new_branch_force)
+{
+	if (new_branch_force) {
+		struct commit *commit = lookup_commit_reference_by_name(new_branch_force);
+		if (!commit)
+			printf_ln(_("Preparing worktree (new branch '%s')"), new_branch_force);
+		else
+			printf_ln(_("Preparing worktree (resetting branch '%s' (was at %s))"),
+				  new_branch_force,
+				  find_unique_abbrev(commit->object.oid.hash,
+						     DEFAULT_ABBREV));
+	} else if (new_branch) {
+		printf_ln(_("Preparing worktree (new branch '%s')"), new_branch);
+	} else {
+		struct commit *commit = lookup_commit_reference_by_name(branch);
+		if (!commit)
+			die(_("invalid reference: %s"), branch);
+		printf_ln(_("Preparing worktree (detached HEAD %s)"),
+			  find_unique_abbrev(commit->object.oid.hash,
+					     DEFAULT_ABBREV));
+	}
+}
+
 static int add(int ac, const char **av, const char *prefix)
 {
 	struct add_opts opts;
@@ -434,6 +457,8 @@ static int add(int ac, const char **av, const char *prefix)
 		}
 	}
 
+	print_preparing_worktree_line(branch, new_branch, new_branch_force);
+
 	if (new_branch) {
 		struct child_process cp = CHILD_PROCESS_INIT;
 		cp.git_cmd = 1;

-- 
2.17.0.252.gfe0a9eaf31
Junio C Hamano· Apr 16, 2018, 02:09 UTC · re: Thomas Gummerer · lore

Re: [PATCH v7 2/4] worktree: improve message when creating a new worktree

Thomas Gummerer <t.gummerer@gmail.com> writes:
Show 9 quoted lines
> Currently 'git worktree add' produces output like the following:
>
>     Preparing ../foo (identifier foo)
>     HEAD is now at 26da330922 <title>
>
> The '../foo' is the path where the worktree is created, which the user
> has just given on the command line.  The identifier is an internal
> implementation detail, which is not particularly relevant for the user
> and indeed isn't mentioned explicitly anywhere in the man page.

OK. Maybe there once was a place or two that took the identifier as an input to name a specific worktree to work on (perhaps "prune"?), but if we no longer do that (which makes sense, as we should be able to uniquely identify a worktree by the path to it), then it makes perfect sense to prevent it from appearing in the UI.

> Instead of this message, print a message that gives the user a bit more
> detail of what exactly 'git worktree' is doing.  There are various dwim
> modes which are perform some magic under the hood, which should be
s/are perform/perform/, I think (no need to reroll, only to fix this).
Show 6 quoted lines
> Additionally currently the "Preparing ..." line is printed to stderr,
> while the "HEAD is now at ..." line is printed to stdout by 'git reset
> --hard', which is used internally by 'git worktree add'.  Fix this
> inconsistency by printing the "Preparing ..." message to stdout as
> well.  As "Preparing ..." is not an error, stdout also seems like the
> more appropriate output stream.

I think it is a bug for reset to give this kind of informational message to the standard output stream. A rule of thumb I use is "is this something that a user who wants quiet operation would wish to squelch with --quiet option?" and if the answer is yes, it should go to the standard error output, so info and progress should go to the standard output in general.

But I am OK to unify to the standard output with this patch. We may want to come back and correct _both_ this new message and what reset says, but that is outside the scope of this topic.

Thanks.
Thomas Gummerer· Apr 23, 2018, 18:55 UTC · re: Junio C Hamano · lore

Re: [PATCH v7 2/4] worktree: improve message when creating a new worktree

On 04/16, Junio C Hamano wrote:
Show 23 quoted lines
> Thomas Gummerer <t.gummerer@gmail.com> writes:
> 
> > Currently 'git worktree add' produces output like the following:
> >
> >     Preparing ../foo (identifier foo)
> >     HEAD is now at 26da330922 <title>
> >
> > The '../foo' is the path where the worktree is created, which the user
> > has just given on the command line.  The identifier is an internal
> > implementation detail, which is not particularly relevant for the user
> > and indeed isn't mentioned explicitly anywhere in the man page.
> 
> OK.  Maybe there once was a place or two that took the identifier as
> an input to name a specific worktree to work on (perhaps "prune"?),
> but if we no longer do that (which makes sense, as we should be able
> to uniquely identify a worktree by the path to it), then it makes
> perfect sense to prevent it from appearing in the UI.
> 
> > Instead of this message, print a message that gives the user a bit more
> > detail of what exactly 'git worktree' is doing.  There are various dwim
> > modes which are perform some magic under the hood, which should be
> 
> s/are perform/perform/, I think (no need to reroll, only to fix this).
Now that I'm re-rolling anyway, I'll fix this as well, thanks.
Show 13 quoted lines
> > Additionally currently the "Preparing ..." line is printed to stderr,
> > while the "HEAD is now at ..." line is printed to stdout by 'git reset
> > --hard', which is used internally by 'git worktree add'.  Fix this
> > inconsistency by printing the "Preparing ..." message to stdout as
> > well.  As "Preparing ..." is not an error, stdout also seems like the
> > more appropriate output stream.
> 
> I think it is a bug for reset to give this kind of informational
> message to the standard output stream.  A rule of thumb I use is "is
> this something that a user who wants quiet operation would wish to
> squelch with --quiet option?" and if the answer is yes, it should go
> to the standard error output, so info and progress should go to the
> standard output in general.
I assume you meant "standard error output" just above?
> But I am OK to unify to the standard output with this patch.  We may
> want to come back and correct _both_ this new message and what reset
> says, but that is outside the scope of this topic.

Cool, I'd rather not add more moving pieces to this series, as it's already at v7 (v8 soon), but I'm happy to have a look at this and fix it on top once the dust settled on this series.

> Thanks.
Eric Sunshine· Apr 23, 2018, 04:27 UTC · re: Thomas Gummerer · lore

Re: [PATCH v7 2/4] worktree: improve message when creating a new worktree

On Sun, Apr 15, 2018 at 4:29 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
Show 27 quoted lines
> Currently 'git worktree add' produces output like the following:
>
>     Preparing ../foo (identifier foo)
>     HEAD is now at 26da330922 <title>
> [...]
> Instead of this message, print a message that gives the user a bit more
> detail of what exactly 'git worktree' is doing.  There are various dwim
> modes which are perform some magic under the hood, which should be
> helpful to users.  Just from the output of the command it is not always
> visible to users what exactly has happened.
>
> Help the users a bit more by modifying the "Preparing ..." message and
> adding some additional information of what 'git worktree add' did under
> the hood, while not displaying the identifier anymore.
>
> Currently this ends up in three different cases:
>
>   - 'git worktree add -b ...' or 'git worktree add <path>' [...]
>
>   - 'git worktree add -B ...', which may either create a new branch if
>     the branch with the given name does not exist yet, or resets an
>     existing branch to the current HEAD, or the commit-ish given.
>     Depending on which action is taken, we'll end up with the following
>     output:
>
>       Preparing worktree (resetting branch 'next' (was at caa68db14))
>       HEAD is now at 26da330922 <title>

The (...) embedded inside another (...) is ugly and hard to read. Better perhaps:

    Preparing worktree (resetting branch 'next'; was at caa68db14)

Not necessarily worth a re-roll. It would be nice to see this series land; perhaps this can be tweaked later.

Show 11 quoted lines
>     or:
>
>       Preparing worktree (new branch '<branch>')
>       HEAD is now at 26da330922 <title>
>
>   - 'git worktree add --detach' or 'git worktree add <path> <branch>',
>     both of which create a new worktree with a detached HEAD, for which
>     we will print the following output:
>
>       Preparing worktree (detached HEAD 26da330922)
>       HEAD is now at 26da330922 <title>

This is inaccurate, isn't it? Certainly, specifying something like "origin/floop" for <branch> ends up detached:

    % git worktree add w1 origin/floop
    ...
    % git worktree list
    /proj     fe0a9eaf31 [master]
    /proj/w1  b46fe60e1d (detached HEAD)
but specifying an existing local branch (say "wip") does not end up detached:
    % git worktree add w2 wip
    ...
    % git worktree list
    /proj     fe0a9eaf31 [master]
    /proj/w1  b46fe60e1d (detached HEAD)
    /proj/w2  820ed2a513 [wip]
Show 9 quoted lines
> Additionally currently the "Preparing ..." line is printed to stderr,
> while the "HEAD is now at ..." line is printed to stdout by 'git reset
> --hard', which is used internally by 'git worktree add'.  Fix this
> inconsistency by printing the "Preparing ..." message to stdout as
> well.  As "Preparing ..." is not an error, stdout also seems like the
> more appropriate output stream.
>
> Helped-by: Eric Sunshine <sunshine@sunshineco.com>
> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Thomas Gummerer· Apr 23, 2018, 18:50 UTC · re: Eric Sunshine · lore

Re: [PATCH v7 2/4] worktree: improve message when creating a new worktree

On 04/23, Eric Sunshine wrote:
Show 36 quoted lines
> On Sun, Apr 15, 2018 at 4:29 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
> > Currently 'git worktree add' produces output like the following:
> >
> >     Preparing ../foo (identifier foo)
> >     HEAD is now at 26da330922 <title>
> > [...]
> > Instead of this message, print a message that gives the user a bit more
> > detail of what exactly 'git worktree' is doing.  There are various dwim
> > modes which are perform some magic under the hood, which should be
> > helpful to users.  Just from the output of the command it is not always
> > visible to users what exactly has happened.
> >
> > Help the users a bit more by modifying the "Preparing ..." message and
> > adding some additional information of what 'git worktree add' did under
> > the hood, while not displaying the identifier anymore.
> >
> > Currently this ends up in three different cases:
> >
> >   - 'git worktree add -b ...' or 'git worktree add <path>' [...]
> >
> >   - 'git worktree add -B ...', which may either create a new branch if
> >     the branch with the given name does not exist yet, or resets an
> >     existing branch to the current HEAD, or the commit-ish given.
> >     Depending on which action is taken, we'll end up with the following
> >     output:
> >
> >       Preparing worktree (resetting branch 'next' (was at caa68db14))
> >       HEAD is now at 26da330922 <title>
> 
> The (...) embedded inside another (...) is ugly and hard to read.
> Better perhaps:
> 
>     Preparing worktree (resetting branch 'next'; was at caa68db14)
> 
> Not necessarily worth a re-roll. It would be nice to see this series
> land; perhaps this can be tweaked later.
I'll tweak it while fixing the other bit.
Show 14 quoted lines
> >     or:
> >
> >       Preparing worktree (new branch '<branch>')
> >       HEAD is now at 26da330922 <title>
> >
> >   - 'git worktree add --detach' or 'git worktree add <path> <branch>',
> >     both of which create a new worktree with a detached HEAD, for which
> >     we will print the following output:
> >
> >       Preparing worktree (detached HEAD 26da330922)
> >       HEAD is now at 26da330922 <title>
> 
> This is inaccurate, isn't it? Certainly, specifying something like
> "origin/floop" for <branch> ends up detached:

Ah indeed, this was the case I missed. I thought I managed to go through all of them, but this one slipped through the cracks. Thanks for catching this, will fix in a re-roll.

Show 24 quoted lines
>     % git worktree add w1 origin/floop
>     ...
>     % git worktree list
>     /proj     fe0a9eaf31 [master]
>     /proj/w1  b46fe60e1d (detached HEAD)
> 
> but specifying an existing local branch (say "wip") does not end up detached:
> 
>     % git worktree add w2 wip
>     ...
>     % git worktree list
>     /proj     fe0a9eaf31 [master]
>     /proj/w1  b46fe60e1d (detached HEAD)
>     /proj/w2  820ed2a513 [wip]
> 
> > Additionally currently the "Preparing ..." line is printed to stderr,
> > while the "HEAD is now at ..." line is printed to stdout by 'git reset
> > --hard', which is used internally by 'git worktree add'.  Fix this
> > inconsistency by printing the "Preparing ..." message to stdout as
> > well.  As "Preparing ..." is not an error, stdout also seems like the
> > more appropriate output stream.
> >
> > Helped-by: Eric Sunshine <sunshine@sunshineco.com>
> > Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Thomas Gummerer· Apr 15, 2018, 20:29 UTC · re: Thomas Gummerer · lore

[PATCH v7 4/4] worktree: teach "add" to check out existing branches

Currently 'git worktree add <path>' creates a new branch named after the basename of the path by default. If a branch with that name already exists, the command refuses to do anything, unless the '--force' option is given.

However we can do a little better than that, and check the branch out if it is not checked out anywhere else. This will help users who just want to check an existing branch out into a new worktree, and save a few keystrokes.

As the current behaviour is to simply 'die()' when a branch with the name of the basename of the path already exists, there are no backwards compatibility worries here.

We will still 'die()' if the branch is checked out in another worktree, unless the --force flag is passed.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 Documentation/git-worktree.txt |  9 +++++++--
 builtin/worktree.c             | 30 ++++++++++++++++++++++++------
 t/t2025-worktree-add.sh        | 26 +++++++++++++++++++-------
 3 files changed, 50 insertions(+), 15 deletions(-)
Show changes to 3 files +50 −15

Documentation/git-worktree.txt, builtin/worktree.c, t/t2025-worktree-add.sh

diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index 41585f535d..5d54f36a71 100644
--- a/Documentation/git-worktree.txt
+++ b/Documentation/git-worktree.txt
@@ -61,8 +61,13 @@ $ git worktree add --track -b <branch> <path> <remote>/<branch>
 ------------
 +
 If `<commit-ish>` is omitted and neither `-b` nor `-B` nor `--detach` used,
-then, as a convenience, a new branch based at HEAD is created automatically,
-as if `-b $(basename <path>)` was specified.
+then, as a convenience, the new worktree is associated with a branch
+(call it `<branch>`) named after `$(basename <path>)`.  If `<branch>`
+doesn't exist, a new branch based on HEAD is automatically created as
+if `-b <branch>` was given.  If `<branch>` does exist, it will be
+checked out in the new worktree, if it's not checked out anywhere
+else, otherwise the command will refuse to create the worktree (unless
+`--force` is used).
 
 list::
 
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 893139629a..f5a5283b39 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -355,9 +355,12 @@ static int add_worktree(const char *path, const char *refname,
 
 static void print_preparing_worktree_line(const char *branch,
 					  const char *new_branch,
-					  const char *new_branch_force)
+					  const char *new_branch_force,
+					  int checkout_existing_branch)
 {
-	if (new_branch_force) {
+	if (checkout_existing_branch) {
+		printf_ln(_("Preparing worktree (checking out '%s')"), branch);
+	} else if (new_branch_force) {
 		struct commit *commit = lookup_commit_reference_by_name(new_branch_force);
 		if (!commit)
 			printf_ln(_("Preparing worktree (new branch '%s')"), new_branch_force);
@@ -378,11 +381,23 @@ static void print_preparing_worktree_line(const char *branch,
 	}
 }
 
-static const char *dwim_branch(const char *path, const char **new_branch)
+static const char *dwim_branch(const char *path, const char **new_branch,
+			       int *checkout_existing_branch)
 {
 	int n;
 	const char *s = worktree_basename(path, &n);
-	*new_branch = xstrndup(s, n);
+	const char *branchname = xstrndup(s, n);
+	struct strbuf ref = STRBUF_INIT;
+
+	if (!strbuf_check_branch_ref(&ref, branchname) &&
+	    ref_exists(ref.buf)) {
+		*checkout_existing_branch = 1;
+		strbuf_release(&ref);
+		UNLEAK(branchname);
+		return branchname;
+	}
+
+	*new_branch = branchname;
 	if (guess_remote) {
 		struct object_id oid;
 		const char *remote =
@@ -397,6 +412,7 @@ static int add(int ac, const char **av, const char *prefix)
 	struct add_opts opts;
 	const char *new_branch_force = NULL;
 	char *path;
+	int checkout_existing_branch = 0;
 	const char *branch;
 	const char *new_branch = NULL;
 	const char *opt_track = NULL;
@@ -444,7 +460,8 @@ static int add(int ac, const char **av, const char *prefix)
 	}
 
 	if (ac < 2 && !new_branch && !opts.detach) {
-		const char *s = dwim_branch(path, &new_branch);
+		const char *s = dwim_branch(path, &new_branch,
+					    &checkout_existing_branch);
 		if (s)
 			branch = s;
 	}
@@ -464,7 +481,8 @@ static int add(int ac, const char **av, const char *prefix)
 		}
 	}
 
-	print_preparing_worktree_line(branch, new_branch, new_branch_force);
+	print_preparing_worktree_line(branch, new_branch, new_branch_force,
+				      checkout_existing_branch);
 
 	if (new_branch) {
 		struct child_process cp = CHILD_PROCESS_INIT;
diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
index 2b95944973..ad38507d00 100755
--- a/t/t2025-worktree-add.sh
+++ b/t/t2025-worktree-add.sh
@@ -198,13 +198,25 @@ test_expect_success '"add" with <branch> omitted' '
 	test_cmp_rev HEAD bat
 '
 
-test_expect_success '"add" auto-vivify does not clobber existing branch' '
-	test_commit c1 &&
-	test_commit c2 &&
-	git branch precious HEAD~1 &&
-	test_must_fail git worktree add precious &&
-	test_cmp_rev HEAD~1 precious &&
-	test_path_is_missing precious
+test_expect_success '"add" checks out existing branch of dwimd name' '
+	git branch dwim HEAD~1 &&
+	git worktree add dwim &&
+	test_cmp_rev HEAD~1 dwim &&
+	(
+		cd dwim &&
+		test_cmp_rev HEAD dwim
+	)
+'
+
+test_expect_success '"add <path>" dwim fails with checked out branch' '
+	git checkout -b test-branch &&
+	test_must_fail git worktree add test-branch &&
+	test_path_is_missing test-branch
+'
+
+test_expect_success '"add --force" with existing dwimd name doesnt die' '
+	git checkout test-branch &&
+	git worktree add --force test-branch
 '
 
 test_expect_success '"add" no auto-vivify with --detach and <branch> omitted' '

-- 
2.17.0.252.gfe0a9eaf31
Eric Sunshine· Apr 23, 2018, 04:52 UTC · re: Thomas Gummerer · lore

Re: [PATCH v7 0/4] worktree: teach "add" to check out existing branches

On Sun, Apr 15, 2018 at 4:29 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
Show 6 quoted lines
> The main change once again in this series is the user interface.  It
> feels like we went in a complete circle here now, as this iteration is
> bringing the "Preparing ..." line back (although in a slightly
> different form than the original), and is moving away from printing
> it's own "HEAD is now at..." line again.  This also means we don't
> need the new hidden option to 'git reset' anymore, which is nice.

I'm glad to see the proposed hidden git-reset option go away, and am likewise happy to see that worktree no longer wants to print "HEAD is now at" itself. I'm much more pleased with the direction this series is now taking than in earlier rounds. It's also much simpler, which is a nice plus.

Show 7 quoted lines
> I do like the new UI more than what we had in the last round (which I
> already liked more than the original UI) :)
>
> To demonstrate the UI updates, let's compare the new UI and the old UI
> again.  This is the same commands as used for the demonstration in the
> last iteration, so please have a look at <20180331151804.30380-1-t.gummerer@gmail.com>
> for an example of what it looked like after the last round.

Thanks for presenting examples of the new UI under various conditions. Like you, I find the new "Preparing..." message superior to and much more useful than the original.

Aside from the problem pointed out in my review of 2/4 in which it incorrectly shows "detached HEAD" for "git worktree add wt existing-local-branch", I think this series is just about ready, and hope to see it land with the next re-roll.

Thanks for working on it.
Thomas Gummerer· Apr 23, 2018, 19:38 UTC · re: Thomas Gummerer · lore

[PATCH v8 0/4] worktree: teach "add" to check out existing branches

Thanks Eric and Junio for the review the suggestions in the last round.

Previous rounds are at <20180121120208.12760-1-t.gummerer@gmail.com>, <20180204221305.28300-1-t.gummerer@gmail.com>, <20180317220830.30963-1-t.gummerer@gmail.com>, <20180317222219.4940-1-t.gummerer@gmail.com>, <20180325134947.25828-1-t.gummerer@gmail.com>, <20180331151804.30380-1-t.gummerer@gmail.com> and <20180415202917.4360-1-t.gummerer@gmail.com>.

This round updates the output for "resetting branch ..." to not have braces embedded inside of another pair of braces, and is not correctly printing "checking out '<branch>'" when 'git worktree add <path> <local-branch>' is used. Both these changes are in patch 2/4, the other patches are the same as in the previous round.

Interdiff below:
Show changes to builtin/worktree.c +18 −9
diff --git a/builtin/worktree.c b/builtin/worktree.c
index f5a5283b39..d52495f312 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -353,7 +353,8 @@ static int add_worktree(const char *path, const char *refname,
 	return ret;
 }
 
-static void print_preparing_worktree_line(const char *branch,
+static void print_preparing_worktree_line(int detach,
+					  const char *branch,
 					  const char *new_branch,
 					  const char *new_branch_force,
 					  int checkout_existing_branch)
@@ -365,19 +366,27 @@ static void print_preparing_worktree_line(const char *branch,
 		if (!commit)
 			printf_ln(_("Preparing worktree (new branch '%s')"), new_branch_force);
 		else
-			printf_ln(_("Preparing worktree (resetting branch '%s' (was at %s))"),
+			printf_ln(_("Preparing worktree (resetting branch '%s'; was at %s)"),
 				  new_branch_force,
 				  find_unique_abbrev(commit->object.oid.hash,
 						     DEFAULT_ABBREV));
 	} else if (new_branch) {
 		printf_ln(_("Preparing worktree (new branch '%s')"), new_branch);
 	} else {
-		struct commit *commit = lookup_commit_reference_by_name(branch);
-		if (!commit)
-			die(_("invalid reference: %s"), branch);
-		printf_ln(_("Preparing worktree (detached HEAD %s)"),
-			  find_unique_abbrev(commit->object.oid.hash,
-					     DEFAULT_ABBREV));
+		struct strbuf s = STRBUF_INIT;
+		if (!detach && !strbuf_check_branch_ref(&s, branch) &&
+		    ref_exists(s.buf))
+			printf_ln(_("Preparing worktree (checking out '%s')"),
+				  branch);
+		else {
+			struct commit *commit = lookup_commit_reference_by_name(branch);
+			if (!commit)
+				die(_("invalid reference: %s"), branch);
+			printf_ln(_("Preparing worktree (detached HEAD %s)"),
+				  find_unique_abbrev(commit->object.oid.hash,
+						     DEFAULT_ABBREV));
+		}
+		strbuf_release(&s);
 	}
 }
 
@@ -481,7 +490,7 @@ static int add(int ac, const char **av, const char *prefix)
 		}
 	}
 
-	print_preparing_worktree_line(branch, new_branch, new_branch_force,
+	print_preparing_worktree_line(opts.detach, branch, new_branch, new_branch_force,
 				      checkout_existing_branch);
 
 	if (new_branch) {

Thomas Gummerer (4):
  worktree: remove extra members from struct add_opts
  worktree: improve message when creating a new worktree
  worktree: factor out dwim_branch function
  worktree: teach "add" to check out existing branches

 Documentation/git-worktree.txt |   9 +++-
 builtin/worktree.c             | 111 +++++++++++++++++++++++++++++++----------
 t/t2025-worktree-add.sh        |  26 +++++++---
 3 files changed, 110 insertions(+), 36 deletions(-)

-- 
2.16.1.74.g7afd1c25cc.dirty
Thomas Gummerer· Apr 23, 2018, 19:38 UTC · re: Thomas Gummerer · lore

[PATCH v8 1/4] worktree: remove extra members from struct add_opts

There are two members of 'struct add_opts', which are only used inside the 'add()' function, but being part of 'struct add_opts' they are needlessly also passed to the 'add_worktree' function.

Make them local to the 'add()' function to make it clearer where they are used.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 builtin/worktree.c | 32 +++++++++++++++-----------------
 1 file changed, 15 insertions(+), 17 deletions(-)
Show changes to builtin/worktree.c +15 −17
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 7cef5b120b..4d96a21a45 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -27,8 +27,6 @@ struct add_opts {
 	int detach;
 	int checkout;
 	int keep_locked;
-	const char *new_branch;
-	int force_new_branch;
 };
 
 static int show_only;
@@ -363,10 +361,11 @@ static int add(int ac, const char **av, const char *prefix)
 	const char *new_branch_force = NULL;
 	char *path;
 	const char *branch;
+	const char *new_branch = NULL;
 	const char *opt_track = NULL;
 	struct option options[] = {
 		OPT__FORCE(&opts.force, N_("checkout <branch> even if already checked out in other worktree")),
-		OPT_STRING('b', NULL, &opts.new_branch, N_("branch"),
+		OPT_STRING('b', NULL, &new_branch, N_("branch"),
 			   N_("create a new branch")),
 		OPT_STRING('B', NULL, &new_branch_force, N_("branch"),
 			   N_("create or reset a branch")),
@@ -384,7 +383,7 @@ static int add(int ac, const char **av, const char *prefix)
 	memset(&opts, 0, sizeof(opts));
 	opts.checkout = 1;
 	ac = parse_options(ac, av, prefix, options, worktree_usage, 0);
-	if (!!opts.detach + !!opts.new_branch + !!new_branch_force > 1)
+	if (!!opts.detach + !!new_branch + !!new_branch_force > 1)
 		die(_("-b, -B, and --detach are mutually exclusive"));
 	if (ac < 1 || ac > 2)
 		usage_with_options(worktree_usage, options);
@@ -395,33 +394,32 @@ static int add(int ac, const char **av, const char *prefix)
 	if (!strcmp(branch, "-"))
 		branch = "@{-1}";
 
-	opts.force_new_branch = !!new_branch_force;
-	if (opts.force_new_branch) {
+	if (new_branch_force) {
 		struct strbuf symref = STRBUF_INIT;
 
-		opts.new_branch = new_branch_force;
+		new_branch = new_branch_force;
 
 		if (!opts.force &&
-		    !strbuf_check_branch_ref(&symref, opts.new_branch) &&
+		    !strbuf_check_branch_ref(&symref, new_branch) &&
 		    ref_exists(symref.buf))
 			die_if_checked_out(symref.buf, 0);
 		strbuf_release(&symref);
 	}
 
-	if (ac < 2 && !opts.new_branch && !opts.detach) {
+	if (ac < 2 && !new_branch && !opts.detach) {
 		int n;
 		const char *s = worktree_basename(path, &n);
-		opts.new_branch = xstrndup(s, n);
+		new_branch = xstrndup(s, n);
 		if (guess_remote) {
 			struct object_id oid;
 			const char *remote =
-				unique_tracking_name(opts.new_branch, &oid);
+				unique_tracking_name(new_branch, &oid);
 			if (remote)
 				branch = remote;
 		}
 	}
 
-	if (ac == 2 && !opts.new_branch && !opts.detach) {
+	if (ac == 2 && !new_branch && !opts.detach) {
 		struct object_id oid;
 		struct commit *commit;
 		const char *remote;
@@ -430,25 +428,25 @@ static int add(int ac, const char **av, const char *prefix)
 		if (!commit) {
 			remote = unique_tracking_name(branch, &oid);
 			if (remote) {
-				opts.new_branch = branch;
+				new_branch = branch;
 				branch = remote;
 			}
 		}
 	}
 
-	if (opts.new_branch) {
+	if (new_branch) {
 		struct child_process cp = CHILD_PROCESS_INIT;
 		cp.git_cmd = 1;
 		argv_array_push(&cp.args, "branch");
-		if (opts.force_new_branch)
+		if (new_branch_force)
 			argv_array_push(&cp.args, "--force");
-		argv_array_push(&cp.args, opts.new_branch);
+		argv_array_push(&cp.args, new_branch);
 		argv_array_push(&cp.args, branch);
 		if (opt_track)
 			argv_array_push(&cp.args, opt_track);
 		if (run_command(&cp))
 			return -1;
-		branch = opts.new_branch;
+		branch = new_branch;
 	} else if (opt_track) {
 		die(_("--[no-]track can only be used if a new branch is created"));
 	}

-- 
2.16.1.74.g7afd1c25cc.dirty
Eric Sunshine· Apr 24, 2018, 03:26 UTC · re: Thomas Gummerer · lore

Re: [PATCH v8 1/4] worktree: remove extra members from struct add_opts

On Mon, Apr 23, 2018 at 3:38 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
Show 22 quoted lines
> There are two members of 'struct add_opts', which are only used inside
> the 'add()' function, but being part of 'struct add_opts' they are
> needlessly also passed to the 'add_worktree' function.
>
> Make them local to the 'add()' function to make it clearer where they
> are used.
>
> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
> ---
> diff --git a/builtin/worktree.c b/builtin/worktree.c
> @@ -27,8 +27,6 @@ struct add_opts {
>         int keep_locked;
> -       const char *new_branch;
> -       int force_new_branch;
>  };
> @@ -395,33 +394,32 @@ static int add(int ac, const char **av, const char *prefix)
> -       if (ac < 2 && !opts.new_branch && !opts.detach) {
> +       if (ac < 2 && !new_branch && !opts.detach) {
>                 int n;
>                 const char *s = worktree_basename(path, &n);
> -               opts.new_branch = xstrndup(s, n);
> +               new_branch = xstrndup(s, n);

Sorry for not noticing this earlier, but when 'new_branch' was part of 'opts', this leaked xstrndup'd string was covered by the UNLEAK(opts) at the end of the function. However, now that 'new_branch' is a standalone variable, it needs its own UNLEAK().

Thomas Gummerer· Apr 23, 2018, 19:38 UTC · re: Thomas Gummerer · lore

[PATCH v8 2/4] worktree: improve message when creating a new worktree

Currently 'git worktree add' produces output like the following:
    Preparing ../foo (identifier foo)
    HEAD is now at 26da330922 <title>

The '../foo' is the path where the worktree is created, which the user has just given on the command line. The identifier is an internal implementation detail, which is not particularly relevant for the user and indeed isn't mentioned explicitly anywhere in the man page.

Instead of this message, print a message that gives the user a bit more detail of what exactly 'git worktree' is doing. There are various dwim modes which perform some magic under the hood, which should be helpful to users. Just from the output of the command it is not always visible to users what exactly has happened.

Help the users a bit more by modifying the "Preparing ..." message and adding some additional information of what 'git worktree add' did under the hood, while not displaying the identifier anymore.

Currently this ends up in three different cases:
  - 'git worktree add -b ...' or 'git worktree add <path>', both of
    which create a new branch, either through the user explicitly
    requesting it, or through 'git worktree add' implicitly creating
    it.  This will end up with the following output:
      Preparing worktree (new branch '<branch>')
      HEAD is now at 26da330922 <title>
  - 'git worktree add -B ...', which may either create a new branch if
    the branch with the given name does not exist yet, or resets an
    existing branch to the current HEAD, or the commit-ish given.
    Depending on which action is taken, we'll end up with the following
    output:
      Preparing worktree (resetting branch 'next'; was at caa68db14)
      HEAD is now at 26da330922 <title>
    or:
      Preparing worktree (new branch '<branch>')
      HEAD is now at 26da330922 <title>
  - 'git worktree add --detach' or 'git worktree add <path>
    <commit-ish>', both of which create a new worktree with a detached
    HEAD, for which we will print the following output:
      Preparing worktree (detached HEAD 26da330922)
      HEAD is now at 26da330922 <title>
  - 'git worktree add <path> <local-branch>', which checks out the
    branch prints the following output:
      Preparing worktree (checking out '<branch>')
      HEAD is now at 47007d5 <title>

Additionally currently the "Preparing ..." line is printed to stderr, while the "HEAD is now at ..." line is printed to stdout by 'git reset --hard', which is used internally by 'git worktree add'. Fix this inconsistency by printing the "Preparing ..." message to stdout as well. As "Preparing ..." is not an error, stdout also seems like the more appropriate output stream.

Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 builtin/worktree.c | 38 ++++++++++++++++++++++++++++++++++++--
 1 file changed, 36 insertions(+), 2 deletions(-)
Show changes to builtin/worktree.c +36 −2
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 4d96a21a45..d348101216 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -301,8 +301,6 @@ static int add_worktree(const char *path, const char *refname,
 	strbuf_addf(&sb, "%s/commondir", sb_repo.buf);
 	write_file(sb.buf, "../..");
 
-	fprintf_ln(stderr, _("Preparing %s (identifier %s)"), path, name);
-
 	argv_array_pushf(&child_env, "%s=%s", GIT_DIR_ENVIRONMENT, sb_git.buf);
 	argv_array_pushf(&child_env, "%s=%s", GIT_WORK_TREE_ENVIRONMENT, path);
 	cp.git_cmd = 1;
@@ -355,6 +353,40 @@ static int add_worktree(const char *path, const char *refname,
 	return ret;
 }
 
+static void print_preparing_worktree_line(int detach,
+					  const char *branch,
+					  const char *new_branch,
+					  const char *new_branch_force)
+{
+	if (new_branch_force) {
+		struct commit *commit = lookup_commit_reference_by_name(new_branch_force);
+		if (!commit)
+			printf_ln(_("Preparing worktree (new branch '%s')"), new_branch_force);
+		else
+			printf_ln(_("Preparing worktree (resetting branch '%s'; was at %s)"),
+				  new_branch_force,
+				  find_unique_abbrev(commit->object.oid.hash,
+						     DEFAULT_ABBREV));
+	} else if (new_branch) {
+		printf_ln(_("Preparing worktree (new branch '%s')"), new_branch);
+	} else {
+		struct strbuf s = STRBUF_INIT;
+		if (!detach && !strbuf_check_branch_ref(&s, branch) &&
+		    ref_exists(s.buf))
+			printf_ln(_("Preparing worktree (checking out '%s')"),
+				  branch);
+		else {
+			struct commit *commit = lookup_commit_reference_by_name(branch);
+			if (!commit)
+				die(_("invalid reference: %s"), branch);
+			printf_ln(_("Preparing worktree (detached HEAD %s)"),
+				  find_unique_abbrev(commit->object.oid.hash,
+						     DEFAULT_ABBREV));
+		}
+		strbuf_release(&s);
+	}
+}
+
 static int add(int ac, const char **av, const char *prefix)
 {
 	struct add_opts opts;
@@ -434,6 +466,8 @@ static int add(int ac, const char **av, const char *prefix)
 		}
 	}
 
+	print_preparing_worktree_line(opts.detach, branch, new_branch, new_branch_force);
+
 	if (new_branch) {
 		struct child_process cp = CHILD_PROCESS_INIT;
 		cp.git_cmd = 1;

-- 
2.16.1.74.g7afd1c25cc.dirty
Eric Sunshine· Apr 24, 2018, 03:58 UTC · re: Thomas Gummerer · lore

Re: [PATCH v8 2/4] worktree: improve message when creating a new worktree

On Mon, Apr 23, 2018 at 3:38 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
Show 21 quoted lines
> Currently 'git worktree add' produces output like the following:
>
>     Preparing ../foo (identifier foo)
>     HEAD is now at 26da330922 <title>
>
> The '../foo' is the path where the worktree is created, which the user
> has just given on the command line.  The identifier is an internal
> implementation detail, which is not particularly relevant for the user
> and indeed isn't mentioned explicitly anywhere in the man page.
>
> Instead of this message, print a message that gives the user a bit more
> detail of what exactly 'git worktree' is doing.  There are various dwim
> modes which perform some magic under the hood, which should be
> helpful to users.  Just from the output of the command it is not always
> visible to users what exactly has happened.
>
> Help the users a bit more by modifying the "Preparing ..." message and
> adding some additional information of what 'git worktree add' did under
> the hood, while not displaying the identifier anymore.
>
> Currently this ends up in three different cases:

You now enumerate four cases, not three. Perhaps: "There are several different cases:"

Show 16 quoted lines
>   - 'git worktree add -b ...' or 'git worktree add <path>', both of
>     which create a new branch, either through the user explicitly
>     requesting it, or through 'git worktree add' implicitly creating
>     it.  This will end up with the following output:
>
>       Preparing worktree (new branch '<branch>')
>       HEAD is now at 26da330922 <title>
>
>   - 'git worktree add -B ...', which may either create a new branch if
>     the branch with the given name does not exist yet, or resets an
>     existing branch to the current HEAD, or the commit-ish given.
>     Depending on which action is taken, we'll end up with the following
>     output:
>
>       Preparing worktree (resetting branch 'next'; was at caa68db14)
>       HEAD is now at 26da330922 <title>
For consistency with the other examples: s/next/<branch>/
Show 14 quoted lines
>     or:
>
>       Preparing worktree (new branch '<branch>')
>       HEAD is now at 26da330922 <title>
>
>   - 'git worktree add --detach' or 'git worktree add <path>
>     <commit-ish>', both of which create a new worktree with a detached
>     HEAD, for which we will print the following output:
>
>       Preparing worktree (detached HEAD 26da330922)
>       HEAD is now at 26da330922 <title>
>
>   - 'git worktree add <path> <local-branch>', which checks out the
>     branch prints the following output:
s/prints/and prints/
>       Preparing worktree (checking out '<branch>')
>       HEAD is now at 47007d5 <title>

s/<branch>/<local-branch>/ would probably be clearer since you use <local-branch> in the example command.

Show 13 quoted lines
> [...]
> Helped-by: Eric Sunshine <sunshine@sunshineco.com>
> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
> ---
> diff --git a/builtin/worktree.c b/builtin/worktree.c
> @@ -355,6 +353,40 @@ static int add_worktree(const char *path, const char *refname,
> +static void print_preparing_worktree_line(int detach,
> +                                         const char *branch,
> +                                         const char *new_branch,
> +                                         const char *new_branch_force)
> +{
> +       if (new_branch_force) {
> +               struct commit *commit = lookup_commit_reference_by_name(new_branch_force);
Nit: By the time this function is called, 'new_branch' contains the
same value as 'new_branch_force' if "-B" was used. 'new_branch' _is_
the name of the new branch, forced or not, and it's easier to reason
about 'new_branch_force' as a mere boolean indicating whether "force"
is in effect. This suggests that the final argument to this function
should be a boolean (int) named either 'force' or 'force_new_branch',
and that 'new_branch' should be used everywhere the code needs to
reference the new branch name (forced or not).
Not worth a re-roll.
Show 23 quoted lines
> +               if (!commit)
> +                       printf_ln(_("Preparing worktree (new branch '%s')"), new_branch_force);
> +               else
> +                       printf_ln(_("Preparing worktree (resetting branch '%s'; was at %s)"),
> +                                 new_branch_force,
> +                                 find_unique_abbrev(commit->object.oid.hash,
> +                                                    DEFAULT_ABBREV));
> +       } else if (new_branch) {
> +               printf_ln(_("Preparing worktree (new branch '%s')"), new_branch);
> +       } else {
> +               struct strbuf s = STRBUF_INIT;
> +               if (!detach && !strbuf_check_branch_ref(&s, branch) &&
> +                   ref_exists(s.buf))
> +                       printf_ln(_("Preparing worktree (checking out '%s')"),
> +                                 branch);
> +               else {
> +                       struct commit *commit = lookup_commit_reference_by_name(branch);
> +                       if (!commit)
> +                               die(_("invalid reference: %s"), branch);
> +                       printf_ln(_("Preparing worktree (detached HEAD %s)"),
> +                                 find_unique_abbrev(commit->object.oid.hash,
> +                                                    DEFAULT_ABBREV));
> +               }

It's too bad this final case duplicates so much code from add_worktree(). Perhaps some future refactoring patch (not part of this series) can consolidate the code.

Show 8 quoted lines
> +               strbuf_release(&s);
> +       }
> +}
> @@ -434,6 +466,8 @@ static int add(int ac, const char **av, const char *prefix)
> +       print_preparing_worktree_line(opts.detach, branch, new_branch, new_branch_force);
> +
>         if (new_branch) {
>                 struct child_process cp = CHILD_PROCESS_INIT;
Thomas Gummerer· Apr 23, 2018, 19:38 UTC · re: Thomas Gummerer · lore

[PATCH v8 3/4] worktree: factor out dwim_branch function

Factor out a dwim_branch function, which takes care of the dwim'ery in 'git worktree add <path>'. It's not too much code currently, but we're adding a new kind of dwim in a subsequent patch, at which point it makes more sense to have it as a separate function.

Factor it out now to reduce the patch noise in the next patch.
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 builtin/worktree.c | 27 +++++++++++++++++----------
 1 file changed, 17 insertions(+), 10 deletions(-)
Show changes to builtin/worktree.c +17 −10
diff --git a/builtin/worktree.c b/builtin/worktree.c
index d348101216..bd4cf4583f 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -387,6 +387,20 @@ static void print_preparing_worktree_line(int detach,
 	}
 }
 
+static const char *dwim_branch(const char *path, const char **new_branch)
+{
+	int n;
+	const char *s = worktree_basename(path, &n);
+	*new_branch = xstrndup(s, n);
+	if (guess_remote) {
+		struct object_id oid;
+		const char *remote =
+			unique_tracking_name(*new_branch, &oid);
+		return remote;
+	}
+	return NULL;
+}
+
 static int add(int ac, const char **av, const char *prefix)
 {
 	struct add_opts opts;
@@ -439,16 +453,9 @@ static int add(int ac, const char **av, const char *prefix)
 	}
 
 	if (ac < 2 && !new_branch && !opts.detach) {
-		int n;
-		const char *s = worktree_basename(path, &n);
-		new_branch = xstrndup(s, n);
-		if (guess_remote) {
-			struct object_id oid;
-			const char *remote =
-				unique_tracking_name(new_branch, &oid);
-			if (remote)
-				branch = remote;
-		}
+		const char *s = dwim_branch(path, &new_branch);
+		if (s)
+			branch = s;
 	}
 
 	if (ac == 2 && !new_branch && !opts.detach) {

-- 
2.16.1.74.g7afd1c25cc.dirty
Thomas Gummerer· Apr 23, 2018, 19:38 UTC · re: Thomas Gummerer · lore

[PATCH v8 4/4] worktree: teach "add" to check out existing branches

Currently 'git worktree add <path>' creates a new branch named after the basename of the path by default. If a branch with that name already exists, the command refuses to do anything, unless the '--force' option is given.

However we can do a little better than that, and check the branch out if it is not checked out anywhere else. This will help users who just want to check an existing branch out into a new worktree, and save a few keystrokes.

As the current behaviour is to simply 'die()' when a branch with the name of the basename of the path already exists, there are no backwards compatibility worries here.

We will still 'die()' if the branch is checked out in another worktree, unless the --force flag is passed.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 Documentation/git-worktree.txt |  9 +++++++--
 builtin/worktree.c             | 30 ++++++++++++++++++++++++------
 t/t2025-worktree-add.sh        | 26 +++++++++++++++++++-------
 3 files changed, 50 insertions(+), 15 deletions(-)
Show changes to 3 files +50 −15

Documentation/git-worktree.txt, builtin/worktree.c, t/t2025-worktree-add.sh

diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index 41585f535d..5d54f36a71 100644
--- a/Documentation/git-worktree.txt
+++ b/Documentation/git-worktree.txt
@@ -61,8 +61,13 @@ $ git worktree add --track -b <branch> <path> <remote>/<branch>
 ------------
 +
 If `<commit-ish>` is omitted and neither `-b` nor `-B` nor `--detach` used,
-then, as a convenience, a new branch based at HEAD is created automatically,
-as if `-b $(basename <path>)` was specified.
+then, as a convenience, the new worktree is associated with a branch
+(call it `<branch>`) named after `$(basename <path>)`.  If `<branch>`
+doesn't exist, a new branch based on HEAD is automatically created as
+if `-b <branch>` was given.  If `<branch>` does exist, it will be
+checked out in the new worktree, if it's not checked out anywhere
+else, otherwise the command will refuse to create the worktree (unless
+`--force` is used).
 
 list::
 
diff --git a/builtin/worktree.c b/builtin/worktree.c
index bd4cf4583f..d52495f312 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -356,9 +356,12 @@ static int add_worktree(const char *path, const char *refname,
 static void print_preparing_worktree_line(int detach,
 					  const char *branch,
 					  const char *new_branch,
-					  const char *new_branch_force)
+					  const char *new_branch_force,
+					  int checkout_existing_branch)
 {
-	if (new_branch_force) {
+	if (checkout_existing_branch) {
+		printf_ln(_("Preparing worktree (checking out '%s')"), branch);
+	} else if (new_branch_force) {
 		struct commit *commit = lookup_commit_reference_by_name(new_branch_force);
 		if (!commit)
 			printf_ln(_("Preparing worktree (new branch '%s')"), new_branch_force);
@@ -387,11 +390,23 @@ static void print_preparing_worktree_line(int detach,
 	}
 }
 
-static const char *dwim_branch(const char *path, const char **new_branch)
+static const char *dwim_branch(const char *path, const char **new_branch,
+			       int *checkout_existing_branch)
 {
 	int n;
 	const char *s = worktree_basename(path, &n);
-	*new_branch = xstrndup(s, n);
+	const char *branchname = xstrndup(s, n);
+	struct strbuf ref = STRBUF_INIT;
+
+	if (!strbuf_check_branch_ref(&ref, branchname) &&
+	    ref_exists(ref.buf)) {
+		*checkout_existing_branch = 1;
+		strbuf_release(&ref);
+		UNLEAK(branchname);
+		return branchname;
+	}
+
+	*new_branch = branchname;
 	if (guess_remote) {
 		struct object_id oid;
 		const char *remote =
@@ -406,6 +421,7 @@ static int add(int ac, const char **av, const char *prefix)
 	struct add_opts opts;
 	const char *new_branch_force = NULL;
 	char *path;
+	int checkout_existing_branch = 0;
 	const char *branch;
 	const char *new_branch = NULL;
 	const char *opt_track = NULL;
@@ -453,7 +469,8 @@ static int add(int ac, const char **av, const char *prefix)
 	}
 
 	if (ac < 2 && !new_branch && !opts.detach) {
-		const char *s = dwim_branch(path, &new_branch);
+		const char *s = dwim_branch(path, &new_branch,
+					    &checkout_existing_branch);
 		if (s)
 			branch = s;
 	}
@@ -473,7 +490,8 @@ static int add(int ac, const char **av, const char *prefix)
 		}
 	}
 
-	print_preparing_worktree_line(opts.detach, branch, new_branch, new_branch_force);
+	print_preparing_worktree_line(opts.detach, branch, new_branch, new_branch_force,
+				      checkout_existing_branch);
 
 	if (new_branch) {
 		struct child_process cp = CHILD_PROCESS_INIT;
diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
index 2b95944973..ad38507d00 100755
--- a/t/t2025-worktree-add.sh
+++ b/t/t2025-worktree-add.sh
@@ -198,13 +198,25 @@ test_expect_success '"add" with <branch> omitted' '
 	test_cmp_rev HEAD bat
 '
 
-test_expect_success '"add" auto-vivify does not clobber existing branch' '
-	test_commit c1 &&
-	test_commit c2 &&
-	git branch precious HEAD~1 &&
-	test_must_fail git worktree add precious &&
-	test_cmp_rev HEAD~1 precious &&
-	test_path_is_missing precious
+test_expect_success '"add" checks out existing branch of dwimd name' '
+	git branch dwim HEAD~1 &&
+	git worktree add dwim &&
+	test_cmp_rev HEAD~1 dwim &&
+	(
+		cd dwim &&
+		test_cmp_rev HEAD dwim
+	)
+'
+
+test_expect_success '"add <path>" dwim fails with checked out branch' '
+	git checkout -b test-branch &&
+	test_must_fail git worktree add test-branch &&
+	test_path_is_missing test-branch
+'
+
+test_expect_success '"add --force" with existing dwimd name doesnt die' '
+	git checkout test-branch &&
+	git worktree add --force test-branch
 '
 
 test_expect_success '"add" no auto-vivify with --detach and <branch> omitted' '

-- 
2.16.1.74.g7afd1c25cc.dirty
Eric Sunshine· Apr 24, 2018, 04:25 UTC · re: Thomas Gummerer · lore

Re: [PATCH v8 4/4] worktree: teach "add" to check out existing branches

On Mon, Apr 23, 2018 at 3:38 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
Show 24 quoted lines
> Currently 'git worktree add <path>' creates a new branch named after the
> basename of the path by default.  If a branch with that name already
> exists, the command refuses to do anything, unless the '--force' option
> is given.
>
> However we can do a little better than that, and check the branch out if
> it is not checked out anywhere else.  This will help users who just want
> to check an existing branch out into a new worktree, and save a few
> keystrokes.
> [...]
> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
> ---
> diff --git a/builtin/worktree.c b/builtin/worktree.c
> @@ -356,9 +356,12 @@ static int add_worktree(const char *path, const char *refname,
>  static void print_preparing_worktree_line(int detach,
>                                           const char *branch,
>                                           const char *new_branch,
> -                                         const char *new_branch_force)
> +                                         const char *new_branch_force,
> +                                         int checkout_existing_branch)
>  {
> -       if (new_branch_force) {
> +       if (checkout_existing_branch) {
> +               printf_ln(_("Preparing worktree (checking out '%s')"), branch);

Is the new 'checkout_existing_branch' argument and this new conditional really needed? Both 'new_branch' and 'new_branch_force' will be NULL in the case of an existing branch, so there should be no need for 'checkout_existing_branch' to state explicitly what is already indicated by their NULLness. With both of them NULL, the existing "(checking out '...')" message later in the function will kick in, so this new condition isn't needed.

Show 14 quoted lines
> +       } else if (new_branch_force) {
> @@ -387,11 +390,23 @@ static void print_preparing_worktree_line(int detach,
> +static const char *dwim_branch(const char *path, const char **new_branch,
> +                              int *checkout_existing_branch)
>  {
>         int n;
>         const char *s = worktree_basename(path, &n);
> -       *new_branch = xstrndup(s, n);
> +       const char *branchname = xstrndup(s, n);
> +       struct strbuf ref = STRBUF_INIT;
> +
> +       if (!strbuf_check_branch_ref(&ref, branchname) &&
> +           ref_exists(ref.buf)) {
> +               *checkout_existing_branch = 1;
See above regarding apparent lack of need for this new variable.
> +               strbuf_release(&ref);
> +               UNLEAK(branchname);
> +               return branchname;
> +       }

Taking the above observation into account, I applied, atop this patch, the following fixup! which removes the 'checkout_existing_branch' gunk and still get the same output:

--- >8 ---
Show changes to builtin/worktree.c +5 −13
diff --git a/builtin/worktree.c b/builtin/worktree.c
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -356,12 +356,9 @@ static int add_worktree(const char *path, const char *refname,
 static void print_preparing_worktree_line(int detach,
 					  const char *branch,
 					  const char *new_branch,
-					  const char *new_branch_force,
-					  int checkout_existing_branch)
+					  const char *new_branch_force)
 {
-	if (checkout_existing_branch) {
-		printf_ln(_("Preparing worktree (checking out '%s')"), branch);
-	} else if (new_branch_force) {
+	if (new_branch_force) {
 		struct commit *commit = lookup_commit_reference_by_name(new_branch_force);
 		if (!commit)
 			printf_ln(_("Preparing worktree (new branch '%s')"), new_branch_force);
@@ -390,8 +387,7 @@ static void print_preparing_worktree_line(int detach,
 	}
 }
 
-static const char *dwim_branch(const char *path, const char **new_branch,
-			       int *checkout_existing_branch)
+static const char *dwim_branch(const char *path, const char **new_branch)
 {
 	int n;
 	const char *s = worktree_basename(path, &n);
@@ -400,7 +396,6 @@ static const char *dwim_branch(const char *path, const char **new_branch,
 
 	if (!strbuf_check_branch_ref(&ref, branchname) &&
 	    ref_exists(ref.buf)) {
-		*checkout_existing_branch = 1;
 		strbuf_release(&ref);
 		UNLEAK(branchname);
 		return branchname;
@@ -421,7 +416,6 @@ static int add(int ac, const char **av, const char *prefix)
 	struct add_opts opts;
 	const char *new_branch_force = NULL;
 	char *path;
-	int checkout_existing_branch = 0;
 	const char *branch;
 	const char *new_branch = NULL;
 	const char *opt_track = NULL;
@@ -469,8 +463,7 @@ static int add(int ac, const char **av, const char *prefix)
 	}
 
 	if (ac < 2 && !new_branch && !opts.detach) {
-		const char *s = dwim_branch(path, &new_branch,
-					    &checkout_existing_branch);
+		const char *s = dwim_branch(path, &new_branch);
 		if (s)
 			branch = s;
 	}
@@ -490,8 +483,7 @@ static int add(int ac, const char **av, const char *prefix)
 		}
 	}
 
-	print_preparing_worktree_line(opts.detach, branch, new_branch, new_branch_force,
-				      checkout_existing_branch);
+	print_preparing_worktree_line(opts.detach, branch, new_branch, new_branch_force);
 
 	if (new_branch) {
 		struct child_process cp = CHILD_PROCESS_INIT;
--- >8 ---
Thomas Gummerer· Apr 24, 2018, 21:56 UTC · re: Thomas Gummerer · lore

[PATCH v9 0/4] worktree: teach "add" to check out existing branches

Previous rounds are at <20180121120208.12760-1-t.gummerer@gmail.com>, <20180204221305.28300-1-t.gummerer@gmail.com>, <20180317220830.30963-1-t.gummerer@gmail.com>, <20180317222219.4940-1-t.gummerer@gmail.com>, <20180325134947.25828-1-t.gummerer@gmail.com>, <20180331151804.30380-1-t.gummerer@gmail.com>, <20180415202917.4360-1-t.gummerer@gmail.com> and <20180423193848.5159-1-t.gummerer@gmail.com>.

Thanks Eric for the review and the suggestions on the previous round.
Changes since the previous round:
- UNLEAK new_branch after it was xstrndup'd
- update the commit message of 2/4 according to Eric's suggestions
- make force_new_branch a boolean flag in
  print_preparing_worktree_line, instead of using it as the branch
  name.  Instead use new_branch as the new branch name everywhere in
  that function.
- get rid of the ckeckout_existing_branch flag
Interdiff below:
Show changes to builtin/worktree.c +9 −17
diff --git a/builtin/worktree.c b/builtin/worktree.c
index d52495f312..d3aeb4877d 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -356,18 +356,15 @@ static int add_worktree(const char *path, const char *refname,
 static void print_preparing_worktree_line(int detach,
 					  const char *branch,
 					  const char *new_branch,
-					  const char *new_branch_force,
-					  int checkout_existing_branch)
+					  int force_new_branch)
 {
-	if (checkout_existing_branch) {
-		printf_ln(_("Preparing worktree (checking out '%s')"), branch);
-	} else if (new_branch_force) {
-		struct commit *commit = lookup_commit_reference_by_name(new_branch_force);
+	if (force_new_branch) {
+		struct commit *commit = lookup_commit_reference_by_name(new_branch);
 		if (!commit)
-			printf_ln(_("Preparing worktree (new branch '%s')"), new_branch_force);
+			printf_ln(_("Preparing worktree (new branch '%s')"), new_branch);
 		else
 			printf_ln(_("Preparing worktree (resetting branch '%s'; was at %s)"),
-				  new_branch_force,
+				  new_branch,
 				  find_unique_abbrev(commit->object.oid.hash,
 						     DEFAULT_ABBREV));
 	} else if (new_branch) {
@@ -390,19 +387,17 @@ static void print_preparing_worktree_line(int detach,
 	}
 }
 
-static const char *dwim_branch(const char *path, const char **new_branch,
-			       int *checkout_existing_branch)
+static const char *dwim_branch(const char *path, const char **new_branch)
 {
 	int n;
 	const char *s = worktree_basename(path, &n);
 	const char *branchname = xstrndup(s, n);
 	struct strbuf ref = STRBUF_INIT;
 
+	UNLEAK(branchname);
 	if (!strbuf_check_branch_ref(&ref, branchname) &&
 	    ref_exists(ref.buf)) {
-		*checkout_existing_branch = 1;
 		strbuf_release(&ref);
-		UNLEAK(branchname);
 		return branchname;
 	}
 
@@ -421,7 +416,6 @@ static int add(int ac, const char **av, const char *prefix)
 	struct add_opts opts;
 	const char *new_branch_force = NULL;
 	char *path;
-	int checkout_existing_branch = 0;
 	const char *branch;
 	const char *new_branch = NULL;
 	const char *opt_track = NULL;
@@ -469,8 +463,7 @@ static int add(int ac, const char **av, const char *prefix)
 	}
 
 	if (ac < 2 && !new_branch && !opts.detach) {
-		const char *s = dwim_branch(path, &new_branch,
-					    &checkout_existing_branch);
+		const char *s = dwim_branch(path, &new_branch);
 		if (s)
 			branch = s;
 	}
@@ -490,8 +483,7 @@ static int add(int ac, const char **av, const char *prefix)
 		}
 	}
 
-	print_preparing_worktree_line(opts.detach, branch, new_branch, new_branch_force,
-				      checkout_existing_branch);
+	print_preparing_worktree_line(opts.detach, branch, new_branch, !!new_branch_force);
 
 	if (new_branch) {
 		struct child_process cp = CHILD_PROCESS_INIT;

Thomas Gummerer (4):
  worktree: remove extra members from struct add_opts
  worktree: improve message when creating a new worktree
  worktree: factor out dwim_branch function
  worktree: teach "add" to check out existing branches

 Documentation/git-worktree.txt |   9 +++-
 builtin/worktree.c             | 103 ++++++++++++++++++++++++++++++-----------
 t/t2025-worktree-add.sh        |  26 ++++++++---
 3 files changed, 102 insertions(+), 36 deletions(-)

-- 
2.16.1.74.g7afd1c25cc.dirty
Thomas Gummerer· Apr 24, 2018, 21:56 UTC · re: Thomas Gummerer · lore

[PATCH v9 1/4] worktree: remove extra members from struct add_opts

There are two members of 'struct add_opts', which are only used inside the 'add()' function, but being part of 'struct add_opts' they are needlessly also passed to the 'add_worktree' function.

Make them local to the 'add()' function to make it clearer where they are used.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 builtin/worktree.c | 33 ++++++++++++++++-----------------
 1 file changed, 16 insertions(+), 17 deletions(-)
Show changes to builtin/worktree.c +16 −17
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 7cef5b120b..bf305c8b7b 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -27,8 +27,6 @@ struct add_opts {
 	int detach;
 	int checkout;
 	int keep_locked;
-	const char *new_branch;
-	int force_new_branch;
 };
 
 static int show_only;
@@ -363,10 +361,11 @@ static int add(int ac, const char **av, const char *prefix)
 	const char *new_branch_force = NULL;
 	char *path;
 	const char *branch;
+	const char *new_branch = NULL;
 	const char *opt_track = NULL;
 	struct option options[] = {
 		OPT__FORCE(&opts.force, N_("checkout <branch> even if already checked out in other worktree")),
-		OPT_STRING('b', NULL, &opts.new_branch, N_("branch"),
+		OPT_STRING('b', NULL, &new_branch, N_("branch"),
 			   N_("create a new branch")),
 		OPT_STRING('B', NULL, &new_branch_force, N_("branch"),
 			   N_("create or reset a branch")),
@@ -384,7 +383,7 @@ static int add(int ac, const char **av, const char *prefix)
 	memset(&opts, 0, sizeof(opts));
 	opts.checkout = 1;
 	ac = parse_options(ac, av, prefix, options, worktree_usage, 0);
-	if (!!opts.detach + !!opts.new_branch + !!new_branch_force > 1)
+	if (!!opts.detach + !!new_branch + !!new_branch_force > 1)
 		die(_("-b, -B, and --detach are mutually exclusive"));
 	if (ac < 1 || ac > 2)
 		usage_with_options(worktree_usage, options);
@@ -395,33 +394,33 @@ static int add(int ac, const char **av, const char *prefix)
 	if (!strcmp(branch, "-"))
 		branch = "@{-1}";
 
-	opts.force_new_branch = !!new_branch_force;
-	if (opts.force_new_branch) {
+	if (new_branch_force) {
 		struct strbuf symref = STRBUF_INIT;
 
-		opts.new_branch = new_branch_force;
+		new_branch = new_branch_force;
 
 		if (!opts.force &&
-		    !strbuf_check_branch_ref(&symref, opts.new_branch) &&
+		    !strbuf_check_branch_ref(&symref, new_branch) &&
 		    ref_exists(symref.buf))
 			die_if_checked_out(symref.buf, 0);
 		strbuf_release(&symref);
 	}
 
-	if (ac < 2 && !opts.new_branch && !opts.detach) {
+	if (ac < 2 && !new_branch && !opts.detach) {
 		int n;
 		const char *s = worktree_basename(path, &n);
-		opts.new_branch = xstrndup(s, n);
+		new_branch = xstrndup(s, n);
+		UNLEAK(new_branch);
 		if (guess_remote) {
 			struct object_id oid;
 			const char *remote =
-				unique_tracking_name(opts.new_branch, &oid);
+				unique_tracking_name(new_branch, &oid);
 			if (remote)
 				branch = remote;
 		}
 	}
 
-	if (ac == 2 && !opts.new_branch && !opts.detach) {
+	if (ac == 2 && !new_branch && !opts.detach) {
 		struct object_id oid;
 		struct commit *commit;
 		const char *remote;
@@ -430,25 +429,25 @@ static int add(int ac, const char **av, const char *prefix)
 		if (!commit) {
 			remote = unique_tracking_name(branch, &oid);
 			if (remote) {
-				opts.new_branch = branch;
+				new_branch = branch;
 				branch = remote;
 			}
 		}
 	}
 
-	if (opts.new_branch) {
+	if (new_branch) {
 		struct child_process cp = CHILD_PROCESS_INIT;
 		cp.git_cmd = 1;
 		argv_array_push(&cp.args, "branch");
-		if (opts.force_new_branch)
+		if (new_branch_force)
 			argv_array_push(&cp.args, "--force");
-		argv_array_push(&cp.args, opts.new_branch);
+		argv_array_push(&cp.args, new_branch);
 		argv_array_push(&cp.args, branch);
 		if (opt_track)
 			argv_array_push(&cp.args, opt_track);
 		if (run_command(&cp))
 			return -1;
-		branch = opts.new_branch;
+		branch = new_branch;
 	} else if (opt_track) {
 		die(_("--[no-]track can only be used if a new branch is created"));
 	}

-- 
2.16.1.74.g7afd1c25cc.dirty
Thomas Gummerer· Apr 24, 2018, 21:56 UTC · re: Thomas Gummerer · lore

[PATCH v9 2/4] worktree: improve message when creating a new worktree

Currently 'git worktree add' produces output like the following:
    Preparing ../foo (identifier foo)
    HEAD is now at 26da330922 <title>

The '../foo' is the path where the worktree is created, which the user has just given on the command line. The identifier is an internal implementation detail, which is not particularly relevant for the user and indeed isn't mentioned explicitly anywhere in the man page.

Instead of this message, print a message that gives the user a bit more detail of what exactly 'git worktree' is doing. There are various dwim modes which perform some magic under the hood, which should be helpful to users. Just from the output of the command it is not always visible to users what exactly has happened.

Help the users a bit more by modifying the "Preparing ..." message and adding some additional information of what 'git worktree add' did under the hood, while not displaying the identifier anymore.

Currently there are several different cases:
  - 'git worktree add -b ...' or 'git worktree add <path>', both of
    which create a new branch, either through the user explicitly
    requesting it, or through 'git worktree add' implicitly creating
    it.  This will end up with the following output:
      Preparing worktree (new branch '<branch>')
      HEAD is now at 26da330922 <title>
  - 'git worktree add -B ...', which may either create a new branch if
    the branch with the given name does not exist yet, or resets an
    existing branch to the current HEAD, or the commit-ish given.
    Depending on which action is taken, we'll end up with the following
    output:
      Preparing worktree (resetting branch '<branch>'; was at caa68db14)
      HEAD is now at 26da330922 <title>
    or:
      Preparing worktree (new branch '<branch>')
      HEAD is now at 26da330922 <title>
  - 'git worktree add --detach' or 'git worktree add <path>
    <commit-ish>', both of which create a new worktree with a detached
    HEAD, for which we will print the following output:
      Preparing worktree (detached HEAD 26da330922)
      HEAD is now at 26da330922 <title>
  - 'git worktree add <path> <local-branch>', which checks out the
    branch and prints the following output:
      Preparing worktree (checking out '<local-branch>')
      HEAD is now at 47007d5 <title>

Additionally currently the "Preparing ..." line is printed to stderr, while the "HEAD is now at ..." line is printed to stdout by 'git reset --hard', which is used internally by 'git worktree add'. Fix this inconsistency by printing the "Preparing ..." message to stdout as well. As "Preparing ..." is not an error, stdout also seems like the more appropriate output stream.

Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 builtin/worktree.c | 38 ++++++++++++++++++++++++++++++++++++--
 1 file changed, 36 insertions(+), 2 deletions(-)
Show changes to builtin/worktree.c +36 −2
diff --git a/builtin/worktree.c b/builtin/worktree.c
index bf305c8b7b..39bf1ea865 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -301,8 +301,6 @@ static int add_worktree(const char *path, const char *refname,
 	strbuf_addf(&sb, "%s/commondir", sb_repo.buf);
 	write_file(sb.buf, "../..");
 
-	fprintf_ln(stderr, _("Preparing %s (identifier %s)"), path, name);
-
 	argv_array_pushf(&child_env, "%s=%s", GIT_DIR_ENVIRONMENT, sb_git.buf);
 	argv_array_pushf(&child_env, "%s=%s", GIT_WORK_TREE_ENVIRONMENT, path);
 	cp.git_cmd = 1;
@@ -355,6 +353,40 @@ static int add_worktree(const char *path, const char *refname,
 	return ret;
 }
 
+static void print_preparing_worktree_line(int detach,
+					  const char *branch,
+					  const char *new_branch,
+					  int force_new_branch)
+{
+	if (force_new_branch) {
+		struct commit *commit = lookup_commit_reference_by_name(new_branch);
+		if (!commit)
+			printf_ln(_("Preparing worktree (new branch '%s')"), new_branch);
+		else
+			printf_ln(_("Preparing worktree (resetting branch '%s'; was at %s)"),
+				  new_branch,
+				  find_unique_abbrev(commit->object.oid.hash,
+						     DEFAULT_ABBREV));
+	} else if (new_branch) {
+		printf_ln(_("Preparing worktree (new branch '%s')"), new_branch);
+	} else {
+		struct strbuf s = STRBUF_INIT;
+		if (!detach && !strbuf_check_branch_ref(&s, branch) &&
+		    ref_exists(s.buf))
+			printf_ln(_("Preparing worktree (checking out '%s')"),
+				  branch);
+		else {
+			struct commit *commit = lookup_commit_reference_by_name(branch);
+			if (!commit)
+				die(_("invalid reference: %s"), branch);
+			printf_ln(_("Preparing worktree (detached HEAD %s)"),
+				  find_unique_abbrev(commit->object.oid.hash,
+						     DEFAULT_ABBREV));
+		}
+		strbuf_release(&s);
+	}
+}
+
 static int add(int ac, const char **av, const char *prefix)
 {
 	struct add_opts opts;
@@ -435,6 +467,8 @@ static int add(int ac, const char **av, const char *prefix)
 		}
 	}
 
+	print_preparing_worktree_line(opts.detach, branch, new_branch, !!new_branch_force);
+
 	if (new_branch) {
 		struct child_process cp = CHILD_PROCESS_INIT;
 		cp.git_cmd = 1;

-- 
2.16.1.74.g7afd1c25cc.dirty
Thomas Gummerer· Apr 24, 2018, 21:56 UTC · re: Thomas Gummerer · lore

[PATCH v9 3/4] worktree: factor out dwim_branch function

Factor out a dwim_branch function, which takes care of the dwim'ery in 'git worktree add <path>'. It's not too much code currently, but we're adding a new kind of dwim in a subsequent patch, at which point it makes more sense to have it as a separate function.

Factor it out now to reduce the patch noise in the next patch.
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 builtin/worktree.c | 29 ++++++++++++++++++-----------
 1 file changed, 18 insertions(+), 11 deletions(-)
Show changes to builtin/worktree.c +18 −11
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 39bf1ea865..6bd32b6090 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -387,6 +387,21 @@ static void print_preparing_worktree_line(int detach,
 	}
 }
 
+static const char *dwim_branch(const char *path, const char **new_branch)
+{
+	int n;
+	const char *s = worktree_basename(path, &n);
+	*new_branch = xstrndup(s, n);
+	UNLEAK(*new_branch);
+	if (guess_remote) {
+		struct object_id oid;
+		const char *remote =
+			unique_tracking_name(*new_branch, &oid);
+		return remote;
+	}
+	return NULL;
+}
+
 static int add(int ac, const char **av, const char *prefix)
 {
 	struct add_opts opts;
@@ -439,17 +454,9 @@ static int add(int ac, const char **av, const char *prefix)
 	}
 
 	if (ac < 2 && !new_branch && !opts.detach) {
-		int n;
-		const char *s = worktree_basename(path, &n);
-		new_branch = xstrndup(s, n);
-		UNLEAK(new_branch);
-		if (guess_remote) {
-			struct object_id oid;
-			const char *remote =
-				unique_tracking_name(new_branch, &oid);
-			if (remote)
-				branch = remote;
-		}
+		const char *s = dwim_branch(path, &new_branch);
+		if (s)
+			branch = s;
 	}
 
 	if (ac == 2 && !new_branch && !opts.detach) {

-- 
2.16.1.74.g7afd1c25cc.dirty
Thomas Gummerer· Apr 24, 2018, 21:56 UTC · re: Thomas Gummerer · lore

[PATCH v9 4/4] worktree: teach "add" to check out existing branches

Currently 'git worktree add <path>' creates a new branch named after the basename of the path by default. If a branch with that name already exists, the command refuses to do anything, unless the '--force' option is given.

However we can do a little better than that, and check the branch out if it is not checked out anywhere else. This will help users who just want to check an existing branch out into a new worktree, and save a few keystrokes.

As the current behaviour is to simply 'die()' when a branch with the name of the basename of the path already exists, there are no backwards compatibility worries here.

We will still 'die()' if the branch is checked out in another worktree, unless the --force flag is passed.

Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 Documentation/git-worktree.txt |  9 +++++++--
 builtin/worktree.c             | 13 +++++++++++--
 t/t2025-worktree-add.sh        | 26 +++++++++++++++++++-------
 3 files changed, 37 insertions(+), 11 deletions(-)
Show changes to 3 files +37 −11

Documentation/git-worktree.txt, builtin/worktree.c, t/t2025-worktree-add.sh

diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index 41585f535d..5d54f36a71 100644
--- a/Documentation/git-worktree.txt
+++ b/Documentation/git-worktree.txt
@@ -61,8 +61,13 @@ $ git worktree add --track -b <branch> <path> <remote>/<branch>
 ------------
 +
 If `<commit-ish>` is omitted and neither `-b` nor `-B` nor `--detach` used,
-then, as a convenience, a new branch based at HEAD is created automatically,
-as if `-b $(basename <path>)` was specified.
+then, as a convenience, the new worktree is associated with a branch
+(call it `<branch>`) named after `$(basename <path>)`.  If `<branch>`
+doesn't exist, a new branch based on HEAD is automatically created as
+if `-b <branch>` was given.  If `<branch>` does exist, it will be
+checked out in the new worktree, if it's not checked out anywhere
+else, otherwise the command will refuse to create the worktree (unless
+`--force` is used).
 
 list::
 
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 6bd32b6090..d3aeb4877d 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -391,8 +391,17 @@ static const char *dwim_branch(const char *path, const char **new_branch)
 {
 	int n;
 	const char *s = worktree_basename(path, &n);
-	*new_branch = xstrndup(s, n);
-	UNLEAK(*new_branch);
+	const char *branchname = xstrndup(s, n);
+	struct strbuf ref = STRBUF_INIT;
+
+	UNLEAK(branchname);
+	if (!strbuf_check_branch_ref(&ref, branchname) &&
+	    ref_exists(ref.buf)) {
+		strbuf_release(&ref);
+		return branchname;
+	}
+
+	*new_branch = branchname;
 	if (guess_remote) {
 		struct object_id oid;
 		const char *remote =
diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
index 2b95944973..ad38507d00 100755
--- a/t/t2025-worktree-add.sh
+++ b/t/t2025-worktree-add.sh
@@ -198,13 +198,25 @@ test_expect_success '"add" with <branch> omitted' '
 	test_cmp_rev HEAD bat
 '
 
-test_expect_success '"add" auto-vivify does not clobber existing branch' '
-	test_commit c1 &&
-	test_commit c2 &&
-	git branch precious HEAD~1 &&
-	test_must_fail git worktree add precious &&
-	test_cmp_rev HEAD~1 precious &&
-	test_path_is_missing precious
+test_expect_success '"add" checks out existing branch of dwimd name' '
+	git branch dwim HEAD~1 &&
+	git worktree add dwim &&
+	test_cmp_rev HEAD~1 dwim &&
+	(
+		cd dwim &&
+		test_cmp_rev HEAD dwim
+	)
+'
+
+test_expect_success '"add <path>" dwim fails with checked out branch' '
+	git checkout -b test-branch &&
+	test_must_fail git worktree add test-branch &&
+	test_path_is_missing test-branch
+'
+
+test_expect_success '"add --force" with existing dwimd name doesnt die' '
+	git checkout test-branch &&
+	git worktree add --force test-branch
 '
 
 test_expect_success '"add" no auto-vivify with --detach and <branch> omitted' '

-- 
2.16.1.74.g7afd1c25cc.dirty
Eric Sunshine· Apr 27, 2018, 07:36 UTC · re: Thomas Gummerer · lore

Re: [PATCH v9 0/4] worktree: teach "add" to check out existing branches

On Tue, Apr 24, 2018 at 5:56 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
Show 11 quoted lines
> Thanks Eric for the review and the suggestions on the previous round.
>
> Changes since the previous round:
>
> - UNLEAK new_branch after it was xstrndup'd
> - update the commit message of 2/4 according to Eric's suggestions
> - make force_new_branch a boolean flag in
>   print_preparing_worktree_line, instead of using it as the branch
>   name.  Instead use new_branch as the new branch name everywhere in
>   that function.
> - get rid of the ckeckout_existing_branch flag

Thanks. I did another full review of all the patches and played around with the new functionality again for good measure. Everything looked good, and I think the patches are now ready to graduate.

For what it's worth, the entire series is:
Reviewed-by: Eric Sunshine <sunshine@sunshineco.com>
Thomas Gummerer· Apr 28, 2018, 16:09 UTC · re: Eric Sunshine · lore

Re: [PATCH v9 0/4] worktree: teach "add" to check out existing branches

On 04/27, Eric Sunshine wrote:
Show 16 quoted lines
> On Tue, Apr 24, 2018 at 5:56 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
> > Thanks Eric for the review and the suggestions on the previous round.
> >
> > Changes since the previous round:
> >
> > - UNLEAK new_branch after it was xstrndup'd
> > - update the commit message of 2/4 according to Eric's suggestions
> > - make force_new_branch a boolean flag in
> >   print_preparing_worktree_line, instead of using it as the branch
> >   name.  Instead use new_branch as the new branch name everywhere in
> >   that function.
> > - get rid of the ckeckout_existing_branch flag
> 
> Thanks. I did another full review of all the patches and played around
> with the new functionality again for good measure. Everything looked
> good, and I think the patches are now ready to graduate.
Thanks for all your review work on this series!
> For what it's worth, the entire series is:
> 
> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com>
Junio C Hamano· Apr 30, 2018, 00:07 UTC · re: Thomas Gummerer · lore

Re: [PATCH v9 0/4] worktree: teach "add" to check out existing branches

Thomas Gummerer <t.gummerer@gmail.com> writes:
Show 19 quoted lines
> On 04/27, Eric Sunshine wrote:
>> On Tue, Apr 24, 2018 at 5:56 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
>> > Thanks Eric for the review and the suggestions on the previous round.
>> >
>> > Changes since the previous round:
>> >
>> > - UNLEAK new_branch after it was xstrndup'd
>> > - update the commit message of 2/4 according to Eric's suggestions
>> > - make force_new_branch a boolean flag in
>> >   print_preparing_worktree_line, instead of using it as the branch
>> >   name.  Instead use new_branch as the new branch name everywhere in
>> >   that function.
>> > - get rid of the ckeckout_existing_branch flag
>> 
>> Thanks. I did another full review of all the patches and played around
>> with the new functionality again for good measure. Everything looked
>> good, and I think the patches are now ready to graduate.
>
> Thanks for all your review work on this series!
Thanks, both.
Junio C Hamano· Mar 18, 2018, 00:24 UTC · re: Thomas Gummerer · lore

Re: [PATCH v3 0/4] worktree: teach "add" to check out existing branches

Thomas Gummerer <t.gummerer@gmail.com> writes:
Show 8 quoted lines
> Previous rounds are at <20180121120208.12760-1-t.gummerer@gmail.com>
> and <20180204221305.28300-1-t.gummerer@gmail.com>.  Thanks Duy, Eric
> and Junio for the comments on the previous round.
>
> Junio: I know it is the rc period right now, but the topic is also
> already queued in 'pu', so I wasn't sure if you prefer me submitting
> this now, or after 2.17 is released.  I'm happy to resend this once
> 2.17 is out if that makes it easier for you.

Mail archives would not forget messages easily, so it is OK if you sent early.

You just need to set expectations low enough, though ;-) Topics that are not in 'next' before -rc1 is tagged will not be in the upcoming release unless there is an extraordinary reason, and reviews, replacing in 'pu', and advancing topics to 'next' will all get lower priority than keeping an eye on breakages in what is already in 'master' until the final.

← back to recent threads