threads / patch / 42878

patchworktree: add: introduce the --name option

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

## tl;dr

14 messages between Jul 19, 2016 and Jul 20, 2016. Diffs are folded; open one to read it.

replies: 13people: 4as markdown or json

Antoine Tenart· Jul 19, 2016, 14:47 UTC · lore

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(-)
Show changes to 3 files +30 −4

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 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
Junio C Hamano· Jul 19, 2016, 18:04 UTC · re: Antoine Tenart · lore

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

Antoine Tenart <antoine.tenart@ack.tf> writes:
Show 15 quoted lines
> 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.

Duy Nguyen· Jul 19, 2016, 18:23 UTC · re: Junio C Hamano · lore

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

On Tue, Jul 19, 2016 at 8:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 29 quoted lines
> 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
Antoine Tenart· Jul 19, 2016, 18:54 UTC · re: Duy Nguyen · lore

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

On Tue, Jul 19, 2016 at 08:23:58PM +0200, Duy Nguyen wrote:
Show 7 quoted lines
> 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
Duy Nguyen· Jul 19, 2016, 19:04 UTC · re: Antoine Tenart · lore

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

On Tue, Jul 19, 2016 at 8:54 PM, Antoine Tenart <antoine.tenart@ack.tf> wrote:
Show 11 quoted lines
> 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).

Show 7 quoted lines
>> 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
Eric Sunshine· Jul 19, 2016, 19:21 UTC · re: Duy Nguyen · lore

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

On Tue, Jul 19, 2016 at 3:04 PM, Duy Nguyen <pclouds@gmail.com> wrote:
Show 5 quoted lines
> 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
Antoine Tenart· Jul 19, 2016, 19:35 UTC · re: Duy Nguyen · lore

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

On Tue, Jul 19, 2016 at 09:04:11PM +0200, Duy Nguyen wrote:
Show 18 quoted lines
> 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
Duy Nguyen· Jul 20, 2016, 14:54 UTC · re: Antoine Tenart · lore

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

On Tue, Jul 19, 2016 at 9:35 PM, Antoine Tenart <antoine.tenart@ack.tf> wrote:
Show 23 quoted lines
> 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
Antoine Tenart· Jul 20, 2016, 16:12 UTC · re: Duy Nguyen · lore

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

On Wed, Jul 20, 2016 at 04:54:40PM +0200, Duy Nguyen wrote:
Show 11 quoted lines
> 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
Antoine Tenart· Jul 19, 2016, 18:45 UTC · re: Junio C Hamano · lore

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

Hi,
On Tue, Jul 19, 2016 at 11:04:59AM -0700, Junio C Hamano wrote:
Show 7 quoted lines
> 
> > 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.
[...]
Show 5 quoted lines
> 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 :-)

Show 5 quoted lines
> 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
Junio C Hamano· Jul 19, 2016, 19:08 UTC · re: Antoine Tenart · lore

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

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 ;-).

Antoine Tenart· Jul 19, 2016, 19:33 UTC · re: Junio C Hamano · lore

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

On Tue, Jul 19, 2016 at 12:08:11PM -0700, Junio C Hamano wrote:
Show 16 quoted lines
> 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
Eric Sunshine· Jul 19, 2016, 18:52 UTC · re: Junio C Hamano · lore

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

On Tue, Jul 19, 2016 at 2:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 19 quoted lines
> 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/

Antoine Tenart· Jul 20, 2016, 06:41 UTC · re: Eric Sunshine · lore

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

Hello Eric,
On Tue, Jul 19, 2016 at 02:52:42PM -0400, Eric Sunshine wrote:
Show 26 quoted lines
> 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

← back to recent threads