[PATCH] worktree: add: introduce the --name option

[PATCH] worktree: add: introduce the --name option

[Antoine Tenart]

Adds a --name option allowing to specify the name of a worktree when
creating it. This allows to have multiple worktrees in directories
having the same name (e.g. project0/foo, project1/foo etc...). This
commit keeps the previous behaviour by making it the default value, i.e.
by using $(basename <path>) as the worktree name when the --name option
isn't used.

Two new test cases are added to ensure the --name option does not break
other functionalities and is working properly.

Finally, the documentation is updated to reflect this --name option
addition.

Signed-off-by: Antoine Tenart <antoine.tenart@ack.tf>
---
 Documentation/git-worktree.txt |  6 +++++-
 builtin/worktree.c             | 14 +++++++++++---
 t/t2025-worktree-add.sh        | 14 ++++++++++++++
 3 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index 7c4cfb0885f4..d05a7a77a89f 100644
--- a/Documentation/git-worktree.txt
+++ b/Documentation/git-worktree.txt
@@ -9,7 +9,7 @@ git-worktree - Manage multiple working trees
 SYNOPSIS
 --------
 [verse]
-'git worktree add' [-f] [--detach] [--checkout] [-b <new-branch>] <path> [<branch>]
+'git worktree add' [-f] [--detach] [--checkout] [-b <new-branch>] [--name <name>] <path> [<branch>]
 'git worktree list' [--porcelain]
 'git worktree prune' [-n] [-v] [--expire <expire>]
 
@@ -84,6 +84,10 @@ OPTIONS
 	exists. `-B` overrides this safeguard, resetting `<new-branch>` to
 	`<branch>`.
 
+--name <name>::
+	With `add`, create a new worktree named `<name>`. Defaults to
+	`$(basename <path>)`.
+
 --detach::
 	With `add`, detach HEAD in the new working tree. See "DETACHED HEAD"
 	in linkgit:git-checkout[1].
diff --git a/builtin/worktree.c b/builtin/worktree.c
index e866844685d5..d435ea7e6d06 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -24,6 +24,7 @@ struct add_opts {
 	int checkout;
 	const char *new_branch;
 	int force_new_branch;
+	const char *name;
 };
 
 static int show_only;
@@ -212,9 +213,14 @@ static int add_worktree(const char *path, const char *refname,
 			die(_("invalid reference: %s"), refname);
 	}
 
-	name = worktree_basename(path, &len);
-	strbuf_addstr(&sb_repo,
-		      git_path("worktrees/%.*s", (int)(path + len - name), name));
+	if (!opts->name) {
+		name = worktree_basename(path, &len);
+		strbuf_addstr(&sb_repo,
+			      git_path("worktrees/%.*s", (int)(path + len - name), name));
+	} else {
+		strbuf_addstr(&sb_repo, git_path("worktrees/%s", opts->name));
+	}
+
 	len = sb_repo.len;
 	if (safe_create_leading_directories_const(sb_repo.buf))
 		die_errno(_("could not create leading directories of '%s'"),
@@ -324,6 +330,8 @@ static int add(int ac, const char **av, const char *prefix)
 			   N_("create a new branch")),
 		OPT_STRING('B', NULL, &new_branch_force, N_("branch"),
 			   N_("create or reset a branch")),
+		OPT_STRING(0, "name", &opts.name, N_("name"),
+			   N_("use a custom worktree name")),
 		OPT_BOOL(0, "detach", &opts.detach, N_("detach HEAD at named commit")),
 		OPT_BOOL(0, "checkout", &opts.checkout, N_("populate the new working tree")),
 		OPT_END()
diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
index 4bcc335a19f9..5a40f5921e4d 100755
--- a/t/t2025-worktree-add.sh
+++ b/t/t2025-worktree-add.sh
@@ -243,6 +243,20 @@ test_expect_success '"add" worktree with --checkout' '
 	test_cmp init.t swamp2/init.t
 '
 
+test_expect_success '"add" worktree with --name' '
+	git worktree add --name kikoo -b foo foo &&
+	test_cmp init.t foo/init.t &&
+	test -d .git/worktrees/kikoo &&
+	test -d foo
+'
+
+test_expect_success '"add" worktree without --name' '
+	git worktree add -b foobar foobar &&
+	test_cmp init.t foobar/init.t &&
+	test -d .git/worktrees/foobar &&
+	test -d foobar
+'
+
 test_expect_success 'put a worktree under rebase' '
 	git worktree add under-rebase &&
 	(
-- 
2.9.2

Re: [PATCH] worktree: add: introduce the --name option

[Junio C Hamano]

Antoine Tenart <antoine.tenart@ack.tf> writes:

> Adds a --name option allowing to specify the name of a worktree when
> creating it. This allows to have multiple worktrees in directories
> having the same name (e.g. project0/foo, project1/foo etc...). This
> commit keeps the previous behaviour by making it the default value, i.e.
> by using $(basename <path>) as the worktree name when the --name option
> isn't used.
>
> Two new test cases are added to ensure the --name option does not break
> other functionalities and is working properly.
>
> Finally, the documentation is updated to reflect this --name option
> addition.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@ack.tf>
> ---

Hmm, is this related to an earlier discussion

    https://public-inbox.org/git/20160625051548.95564-1-barret%40brennie.ca/

in any way, or is it an independent invention?

The conclusion of that discussion thread was roughly "users
shouldn't even _care_ about the name, and if they have to use name
to identify the worktrees to do certain things right now, reducing
the need for such 'certain things', not making it easy to give a
user-defined name to a worktree, is the way to go", IIRC.

Re: [PATCH] worktree: add: introduce the --name option

[Duy Nguyen]

On Tue, Jul 19, 2016 at 8:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Antoine Tenart <antoine.tenart@ack.tf> writes:
>
>> Adds a --name option allowing to specify the name of a worktree when
>> creating it. This allows to have multiple worktrees in directories
>> having the same name (e.g. project0/foo, project1/foo etc...). This
>> commit keeps the previous behaviour by making it the default value, i.e.
>> by using $(basename <path>) as the worktree name when the --name option
>> isn't used.
>>
>> Two new test cases are added to ensure the --name option does not break
>> other functionalities and is working properly.
>>
>> Finally, the documentation is updated to reflect this --name option
>> addition.
>>
>> Signed-off-by: Antoine Tenart <antoine.tenart@ack.tf>
>> ---
>
> Hmm, is this related to an earlier discussion
>
>     https://public-inbox.org/git/20160625051548.95564-1-barret%40brennie.ca/
>
> in any way, or is it an independent invention?
>
> The conclusion of that discussion thread was roughly "users
> shouldn't even _care_ about the name, and if they have to use name
> to identify the worktrees to do certain things right now, reducing
> the need for such 'certain things', not making it easy to give a
> user-defined name to a worktree, is the way to go", IIRC.

080739b (worktree.c: find_worktree() search by path suffix -
2016-06-13) from 'next' should help identify worktrees in this case by
specifying 'project0/foo', 'project1/foo'... Granted it's not fun to
type all that when 'project0/foo' is something long, and bash
completion probably does not help much either.

Note that we may need a unique name elsewhere too, e.g.
refs/worktrees/xyz (even though we haven't settled on this yet). Then
xyz would be more exposed to the user and an easily recognizable name
would be a good thing.
-- 
Duy

Re: [PATCH] worktree: add: introduce the --name option

[Antoine Tenart]

[-- Attachment #1: Type: text/plain, Size: 1871 bytes --]

Hi,

On Tue, Jul 19, 2016 at 11:04:59AM -0700, Junio C Hamano wrote:
> 
> > Adds a --name option allowing to specify the name of a worktree when
> > creating it. This allows to have multiple worktrees in directories
> > having the same name (e.g. project0/foo, project1/foo etc...). This
> > commit keeps the previous behaviour by making it the default value, i.e.
> > by using $(basename <path>) as the worktree name when the --name option
> > isn't used.

[...]

> Hmm, is this related to an earlier discussion
> 
>     https://public-inbox.org/git/20160625051548.95564-1-barret%40brennie.ca/
> 
> in any way, or is it an independent invention?

Completely independent. I made a quick search before doing this... too
quick :-)

> The conclusion of that discussion thread was roughly "users
> shouldn't even _care_ about the name, and if they have to use name
> to identify the worktrees to do certain things right now, reducing
> the need for such 'certain things', not making it easy to give a
> user-defined name to a worktree, is the way to go", IIRC.

I agree that users shouldn't have to deal with this in most cases, and
that's still the default behaviour with this patch. But some use cases
require to change this default name: I use the same repository for each
of my projects using the Linux kernel while working on them in parallel.
So I end up with something like: project1/linux, project2/linux etc...
where other names than 'linux' in each project directory wouldn't really
make sense.

Being able to manually define the name can also be useful in some (rare)
cases, where you reorganize your project directory tree. But that's not
a strong argument for adding this option :-)

There might be other solutions, so I'm open for discussion. I just find
this not-that-magic solution useful.

Thanks!

-- 
Antoine

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] worktree: add: introduce the --name option

[Eric Sunshine]

On Tue, Jul 19, 2016 at 2:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Antoine Tenart <antoine.tenart@ack.tf> writes:
>> Adds a --name option allowing to specify the name of a worktree when
>> creating it. This allows to have multiple worktrees in directories
>> having the same name (e.g. project0/foo, project1/foo etc...). This
>> commit keeps the previous behaviour by making it the default value, i.e.
>> by using $(basename <path>) as the worktree name when the --name option
>> isn't used.
>
> Hmm, is this related to an earlier discussion
>
>     https://public-inbox.org/git/20160625051548.95564-1-barret%40brennie.ca/
>
> in any way, or is it an independent invention?
>
> The conclusion of that discussion thread was roughly "users
> shouldn't even _care_ about the name, and if they have to use name
> to identify the worktrees to do certain things right now, reducing
> the need for such 'certain things', not making it easy to give a
> user-defined name to a worktree, is the way to go", IIRC.

Yes, that's correct. The discussion wandered a bit before starting to
converge at [1] and concluding at [2].

[1]: https://public-inbox.org/git/CAPig%2BcRNUZZBw%3DF-Q2f3Ehc-8T2iBp4kvDusNRGv4ea5nihQVQ%40mail.gmail.com/
[2]: https://public-inbox.org/git/CAPig%2BcSEwib1iFyWE5h8-qTbsAC%2BzsaSDSYQnv6otWoOOjWAeA%40mail.gmail.com/

Re: [PATCH] worktree: add: introduce the --name option

[Antoine Tenart]

[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

On Tue, Jul 19, 2016 at 08:23:58PM +0200, Duy Nguyen wrote:
> On Tue, Jul 19, 2016 at 8:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 
> 080739b (worktree.c: find_worktree() search by path suffix -
> 2016-06-13) from 'next' should help identify worktrees in this case by
> specifying 'project0/foo', 'project1/foo'... Granted it's not fun to
> type all that when 'project0/foo' is something long, and bash
> completion probably does not help much either.

So with this I'll be able to create new worktrees, using paths having
the same basename, but in different let's say "project directories"?

> Note that we may need a unique name elsewhere too, e.g.
> refs/worktrees/xyz (even though we haven't settled on this yet). Then
> xyz would be more exposed to the user and an easily recognizable name
> would be a good thing.

Having a recognisable name surely is a good thing, when performing some
(rare) manual operations. Like moving a worktree (or is there a command
for this?)

Thanks,

-- 
Antoine

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] worktree: add: introduce the --name option

[Duy Nguyen]

On Tue, Jul 19, 2016 at 8:54 PM, Antoine Tenart <antoine.tenart@ack.tf> wrote:
> On Tue, Jul 19, 2016 at 08:23:58PM +0200, Duy Nguyen wrote:
>> On Tue, Jul 19, 2016 at 8:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> 080739b (worktree.c: find_worktree() search by path suffix -
>> 2016-06-13) from 'next' should help identify worktrees in this case by
>> specifying 'project0/foo', 'project1/foo'... Granted it's not fun to
>> type all that when 'project0/foo' is something long, and bash
>> completion probably does not help much either.
>
> So with this I'll be able to create new worktrees, using paths having
> the same basename, but in different let's say "project directories"?

Well, internal name is still out of your control, but if you want to
do something to a worktree you can say "do project0/foo". With 'next'
those verbs can be lock and unlock. We probably can make 'worktree
list' take filter and show just one worktree (and just add "git
worktree show" for that).

>> Note that we may need a unique name elsewhere too, e.g.
>> refs/worktrees/xyz (even though we haven't settled on this yet). Then
>> xyz would be more exposed to the user and an easily recognizable name
>> would be a good thing.
>
> Having a recognisable name surely is a good thing, when performing some
> (rare) manual operations.

What I had in mind was "git log --decorate=more-than-full", foo/HEAD
and foo1/HEAD
do not look as good as project0/HEAD and project1/HEAD (*)

> Like moving a worktree (or is there a command for this?)

Don't touch it. I've been waiting patiently for that patch series to
be reviewed :)
-- 
Duy

Re: [PATCH] worktree: add: introduce the --name option

[Junio C Hamano]

Antoine Tenart <antoine.tenart@ack.tf> writes:

> Being able to manually define the name can also be useful in some (rare)
> cases, where you reorganize your project directory tree. But that's not
> a strong argument for adding this option :-)

Continuing the rationale that rejected the topic from the earlier
discussion thread, the above is like saying that we should expose
inode number more to the users and and allow users to tell a
specific inode number to use when creating an entry in a directory,
which would allow users to edit the directory with binary editor and
replace the entry with the same inode number to move or rename the
path.  The discussion considers that the "name" is an implementation
detail of the worktree subsystem, like inode number is for a
filesystem implementation.  A proper solution would be to invent
"mv" command ;-).

Re: [PATCH] worktree: add: introduce the --name option

[Eric Sunshine]

On Tue, Jul 19, 2016 at 3:04 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Tue, Jul 19, 2016 at 8:54 PM, Antoine Tenart <antoine.tenart@ack.tf> wrote:
>> Like moving a worktree (or is there a command for this?)
>
> Don't touch it. I've been waiting patiently for that patch series to
> be reviewed :)

For newcomers, "that patch series" refers to [1].

If it's any consolation (probably not), I'm still trying to find an
opportunity to review it, however, my computer time is severely
limited these days. In fact, I'm so far behind, I still haven't
reviewed the worktree-lock re-roll (which probably has already hit
'master').

[1]: http://thread.gmane.org/gmane.comp.version-control.git/298194

Re: [PATCH] worktree: add: introduce the --name option

[Antoine Tenart]

[-- Attachment #1: Type: text/plain, Size: 996 bytes --]

On Tue, Jul 19, 2016 at 12:08:11PM -0700, Junio C Hamano wrote:
> Antoine Tenart <antoine.tenart@ack.tf> writes:
> 
> > Being able to manually define the name can also be useful in some (rare)
> > cases, where you reorganize your project directory tree. But that's not
> > a strong argument for adding this option :-)
> 
> Continuing the rationale that rejected the topic from the earlier
> discussion thread, the above is like saying that we should expose
> inode number more to the users and and allow users to tell a
> specific inode number to use when creating an entry in a directory,
> which would allow users to edit the directory with binary editor and
> replace the entry with the same inode number to move or rename the
> path.  The discussion considers that the "name" is an implementation
> detail of the worktree subsystem, like inode number is for a
> filesystem implementation.  A proper solution would be to invent
> "mv" command ;-).

Hehe :-)

-- 
Antoine

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] worktree: add: introduce the --name option

[Antoine Tenart]

[-- Attachment #1: Type: text/plain, Size: 1281 bytes --]

On Tue, Jul 19, 2016 at 09:04:11PM +0200, Duy Nguyen wrote:
> On Tue, Jul 19, 2016 at 8:54 PM, Antoine Tenart <antoine.tenart@ack.tf> wrote:
> > On Tue, Jul 19, 2016 at 08:23:58PM +0200, Duy Nguyen wrote:
> >> On Tue, Jul 19, 2016 at 8:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
> >>
> >> 080739b (worktree.c: find_worktree() search by path suffix -
> >> 2016-06-13) from 'next' should help identify worktrees in this case by
> >> specifying 'project0/foo', 'project1/foo'... Granted it's not fun to
> >> type all that when 'project0/foo' is something long, and bash
> >> completion probably does not help much either.
> >
> > So with this I'll be able to create new worktrees, using paths having
> > the same basename, but in different let's say "project directories"?
> 
> Well, internal name is still out of your control, but if you want to
> do something to a worktree you can say "do project0/foo". With 'next'
> those verbs can be lock and unlock. We probably can make 'worktree
> list' take filter and show just one worktree (and just add "git
> worktree show" for that).

Hmm, so if I understand correctly my use case still won't be supported,
as adding a new worktree with the same basename will fail. Or did I miss
something?

-- 
Antoine

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] worktree: add: introduce the --name option

[Antoine Tenart]

[-- Attachment #1: Type: text/plain, Size: 2151 bytes --]

Hello Eric,

On Tue, Jul 19, 2016 at 02:52:42PM -0400, Eric Sunshine wrote:
> On Tue, Jul 19, 2016 at 2:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > Antoine Tenart <antoine.tenart@ack.tf> writes:
> >> Adds a --name option allowing to specify the name of a worktree when
> >> creating it. This allows to have multiple worktrees in directories
> >> having the same name (e.g. project0/foo, project1/foo etc...). This
> >> commit keeps the previous behaviour by making it the default value, i.e.
> >> by using $(basename <path>) as the worktree name when the --name option
> >> isn't used.
> >
> > Hmm, is this related to an earlier discussion
> >
> >     https://public-inbox.org/git/20160625051548.95564-1-barret%40brennie.ca/
> >
> > in any way, or is it an independent invention?
> >
> > The conclusion of that discussion thread was roughly "users
> > shouldn't even _care_ about the name, and if they have to use name
> > to identify the worktrees to do certain things right now, reducing
> > the need for such 'certain things', not making it easy to give a
> > user-defined name to a worktree, is the way to go", IIRC.
> 
> Yes, that's correct. The discussion wandered a bit before starting to
> converge at [1] and concluding at [2].
> 
> [1]: https://public-inbox.org/git/CAPig%2BcRNUZZBw%3DF-Q2f3Ehc-8T2iBp4kvDusNRGv4ea5nihQVQ%40mail.gmail.com/
> [2]: https://public-inbox.org/git/CAPig%2BcSEwib1iFyWE5h8-qTbsAC%2BzsaSDSYQnv6otWoOOjWAeA%40mail.gmail.com/

Thanks for the links, I've had a look at the discussion. The problem
that raised it was a bit different: it was about reorganizing projects
and directory trees, no about creating a new worktree with the same
basename as an existing one. I've also had a look at 080739b,
introducing find_worktree(), but I don't think that would solve the
issue either.

So we've left with two solutions: being able to specify the worktree
name or having an arbitrary ID (plus some modifications to `git worktree
list`) as you proposed. I guess you prefer the later solution. Is there
any plan to do this, or anything in progress?

Thanks,

-- 
Antoine

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] worktree: add: introduce the --name option

[Duy Nguyen]

On Tue, Jul 19, 2016 at 9:35 PM, Antoine Tenart <antoine.tenart@ack.tf> wrote:
> On Tue, Jul 19, 2016 at 09:04:11PM +0200, Duy Nguyen wrote:
>> On Tue, Jul 19, 2016 at 8:54 PM, Antoine Tenart <antoine.tenart@ack.tf> wrote:
>> > On Tue, Jul 19, 2016 at 08:23:58PM +0200, Duy Nguyen wrote:
>> >> On Tue, Jul 19, 2016 at 8:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> >>
>> >> 080739b (worktree.c: find_worktree() search by path suffix -
>> >> 2016-06-13) from 'next' should help identify worktrees in this case by
>> >> specifying 'project0/foo', 'project1/foo'... Granted it's not fun to
>> >> type all that when 'project0/foo' is something long, and bash
>> >> completion probably does not help much either.
>> >
>> > So with this I'll be able to create new worktrees, using paths having
>> > the same basename, but in different let's say "project directories"?
>>
>> Well, internal name is still out of your control, but if you want to
>> do something to a worktree you can say "do project0/foo". With 'next'
>> those verbs can be lock and unlock. We probably can make 'worktree
>> list' take filter and show just one worktree (and just add "git
>> worktree show" for that).
>
> Hmm, so if I understand correctly my use case still won't be supported,
> as adding a new worktree with the same basename will fail. Or did I miss
> something?

Hm... _what_ fails? If you create two worktrees project0/foo and
project1/foo, you'll get .git/worktrees/foo and .git/worktrees/foo1
but worktree creation should succeed both times. As long as you don't
have to look into .git/worktrees/ everything should be fine, you won't
see foo vs foo1.

If you absolutely have to, I'm thinking of "git --rev-parse
--worktree=<xxx> --git-dir" (or something similar) that will give you
$GIT_DIR to a specific worktree (e.g. .git/worktrees/foo or
.git/worktrees/foo1). Then you can specify "git rev-parse
--worktree=project0/foo --git-dir" and still don't have to see foo vs
foo1.
-- 
Duy

Re: [PATCH] worktree: add: introduce the --name option

[Antoine Tenart]

[-- Attachment #1: Type: text/plain, Size: 738 bytes --]

On Wed, Jul 20, 2016 at 04:54:40PM +0200, Duy Nguyen wrote:
> On Tue, Jul 19, 2016 at 9:35 PM, Antoine Tenart <antoine.tenart@ack.tf> wrote:
> >
> > Hmm, so if I understand correctly my use case still won't be supported,
> > as adding a new worktree with the same basename will fail. Or did I miss
> > something?
> 
> Hm... _what_ fails? If you create two worktrees project0/foo and
> project1/foo, you'll get .git/worktrees/foo and .git/worktrees/foo1
> but worktree creation should succeed both times. As long as you don't
> have to look into .git/worktrees/ everything should be fine, you won't
> see foo vs foo1.

You're right, I don't know why I was sure this wasn't working... Sorry
for the noise :-)

-- 
Antoine

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]