{"thread":{"id":"42878","subject":"[PATCH] worktree: add: introduce the --name option","startedAt":"2016-07-19T14:53:27Z","lastAt":"2016-07-20T16:12:39Z","messageCount":14,"participants":["Antoine Tenart","Junio C Hamano","Duy Nguyen","Eric Sunshine"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"291722","messageId":"20160719144701.571-1-antoine.tenart@ack.tf","threadId":"42878","inReplyTo":null,"subject":"[PATCH] worktree: add: introduce the --name option","fromName":"Antoine Tenart","fromEmail":"antoine.tenart@ack.tf","sentAt":"2016-07-19T14:47:01Z","receivedAt":"2016-07-19T14:53:27Z","isPatch":true,"sender":{"key":"antoine.tenart@ack.tf","avatar":null},"body":"Adds a --name option allowing to specify the name of a worktree when\ncreating it. This allows to have multiple worktrees in directories\nhaving the same name (e.g. project0/foo, project1/foo etc...). This\ncommit keeps the previous behaviour by making it the default value, i.e.\nby using $(basename ) as the worktree name when the --name option\nisn't used.\n\nTwo new test cases are added to ensure the --name option does not break\nother functionalities and is working properly.\n\nFinally, the documentation is updated to reflect this --name option\naddition.\n\nSigned-off-by: Antoine Tenart \n---\n Documentation/git-worktree.txt | 6 +++++-\n builtin/worktree.c | 14 +++++++++++---\n t/t2025-worktree-add.sh | 14 ++++++++++++++\n 3 files changed, 30 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt\nindex 7c4cfb0885f4..d05a7a77a89f 100644\n--- a/Documentation/git-worktree.txt\n+++ b/Documentation/git-worktree.txt\n@@ -9,7 +9,7 @@ git-worktree - Manage multiple working trees\n SYNOPSIS\n --------\n [verse]\n-'git worktree add' [-f] [--detach] [--checkout] [-b ] []\n+'git worktree add' [-f] [--detach] [--checkout] [-b ] [--name ] []\n 'git worktree list' [--porcelain]\n 'git worktree prune' [-n] [-v] [--expire ]\n \n@@ -84,6 +84,10 @@ OPTIONS\n \texists. `-B` overrides this safeguard, resetting `` to\n \t``.\n \n+--name ::\n+\tWith `add`, create a new worktree named ``. Defaults to\n+\t`$(basename )`.\n+\n --detach::\n \tWith `add`, detach HEAD in the new working tree. See \"DETACHED HEAD\"\n \tin linkgit:git-checkout[1].\ndiff --git a/builtin/worktree.c b/builtin/worktree.c\nindex e866844685d5..d435ea7e6d06 100644\n--- a/builtin/worktree.c\n+++ b/builtin/worktree.c\n@@ -24,6 +24,7 @@ struct add_opts {\n \tint checkout;\n \tconst char *new_branch;\n \tint force_new_branch;\n+\tconst char *name;\n };\n \n static int show_only;\n@@ -212,9 +213,14 @@ static int add_worktree(const char *path, const char *refname,\n \t\t\tdie(_(\"invalid reference: %s\"), refname);\n \t}\n \n-\tname = worktree_basename(path, &len);\n-\tstrbuf_addstr(&sb_repo,\n-\t\t git_path(\"worktrees/%.*s\", (int)(path + len - name), name));\n+\tif (!opts->name) {\n+\t\tname = worktree_basename(path, &len);\n+\t\tstrbuf_addstr(&sb_repo,\n+\t\t\t git_path(\"worktrees/%.*s\", (int)(path + len - name), name));\n+\t} else {\n+\t\tstrbuf_addstr(&sb_repo, git_path(\"worktrees/%s\", opts->name));\n+\t}\n+\n \tlen = sb_repo.len;\n \tif (safe_create_leading_directories_const(sb_repo.buf))\n \t\tdie_errno(_(\"could not create leading directories of '%s'\"),\n@@ -324,6 +330,8 @@ static int add(int ac, const char **av, const char *prefix)\n \t\t\t N_(\"create a new branch\")),\n \t\tOPT_STRING('B', NULL, &new_branch_force, N_(\"branch\"),\n \t\t\t N_(\"create or reset a branch\")),\n+\t\tOPT_STRING(0, \"name\", &opts.name, N_(\"name\"),\n+\t\t\t N_(\"use a custom worktree name\")),\n \t\tOPT_BOOL(0, \"detach\", &opts.detach, N_(\"detach HEAD at named commit\")),\n \t\tOPT_BOOL(0, \"checkout\", &opts.checkout, N_(\"populate the new working tree\")),\n \t\tOPT_END()\ndiff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh\nindex 4bcc335a19f9..5a40f5921e4d 100755\n--- a/t/t2025-worktree-add.sh\n+++ b/t/t2025-worktree-add.sh\n@@ -243,6 +243,20 @@ test_expect_success '\"add\" worktree with --checkout' '\n \ttest_cmp init.t swamp2/init.t\n '\n \n+test_expect_success '\"add\" worktree with --name' '\n+\tgit worktree add --name kikoo -b foo foo &&\n+\ttest_cmp init.t foo/init.t &&\n+\ttest -d .git/worktrees/kikoo &&\n+\ttest -d foo\n+'\n+\n+test_expect_success '\"add\" worktree without --name' '\n+\tgit worktree add -b foobar foobar &&\n+\ttest_cmp init.t foobar/init.t &&\n+\ttest -d .git/worktrees/foobar &&\n+\ttest -d foobar\n+'\n+\n test_expect_success 'put a worktree under rebase' '\n \tgit worktree add under-rebase &&\n \t(\n-- \n2.9.2\n\n"},{"id":"291739","messageId":"xmqq7fchh5bo.fsf@gitster.mtv.corp.google.com","threadId":"42878","inReplyTo":"20160719144701.571-1-antoine.tenart@ack.tf","subject":"Re: [PATCH] worktree: add: introduce the --name option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-07-19T18:04:59Z","receivedAt":"2016-07-19T18:05:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Antoine Tenart writes:\n\n> Adds a --name option allowing to specify the name of a worktree when\n> creating it. This allows to have multiple worktrees in directories\n> having the same name (e.g. project0/foo, project1/foo etc...). This\n> commit keeps the previous behaviour by making it the default value, i.e.\n> by using $(basename ) as the worktree name when the --name option\n> isn't used.\n>\n> Two new test cases are added to ensure the --name option does not break\n> other functionalities and is working properly.\n>\n> Finally, the documentation is updated to reflect this --name option\n> addition.\n>\n> Signed-off-by: Antoine Tenart \n> ---\n\nHmm, is this related to an earlier discussion\n\n https://public-inbox.org/git/20160625051548.95564-1-barret%40brennie.ca/\n\nin any way, or is it an independent invention?\n\nThe conclusion of that discussion thread was roughly \"users\nshouldn't even _care_ about the name, and if they have to use name\nto identify the worktrees to do certain things right now, reducing\nthe need for such 'certain things', not making it easy to give a\nuser-defined name to a worktree, is the way to go\", IIRC.\n"},{"id":"291743","messageId":"CACsJy8BDRPK2UKxoMat3i2HL38+KFqw2Qfet2Bev26HXRM-BWA@mail.gmail.com","threadId":"42878","inReplyTo":"xmqq7fchh5bo.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] worktree: add: introduce the --name option","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-07-19T18:23:58Z","receivedAt":"2016-07-19T18:24:32Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Jul 19, 2016 at 8:04 PM, Junio C Hamano wrote:\n> Antoine Tenart writes:\n>\n>> Adds a --name option allowing to specify the name of a worktree when\n>> creating it. This allows to have multiple worktrees in directories\n>> having the same name (e.g. project0/foo, project1/foo etc...). This\n>> commit keeps the previous behaviour by making it the default value, i.e.\n>> by using $(basename ) as the worktree name when the --name option\n>> isn't used.\n>>\n>> Two new test cases are added to ensure the --name option does not break\n>> other functionalities and is working properly.\n>>\n>> Finally, the documentation is updated to reflect this --name option\n>> addition.\n>>\n>> Signed-off-by: Antoine Tenart \n>> ---\n>\n> Hmm, is this related to an earlier discussion\n>\n> https://public-inbox.org/git/20160625051548.95564-1-barret%40brennie.ca/\n>\n> in any way, or is it an independent invention?\n>\n> The conclusion of that discussion thread was roughly \"users\n> shouldn't even _care_ about the name, and if they have to use name\n> to identify the worktrees to do certain things right now, reducing\n> the need for such 'certain things', not making it easy to give a\n> user-defined name to a worktree, is the way to go\", IIRC.\n\n080739b (worktree.c: find_worktree() search by path suffix -\n2016-06-13) from 'next' should help identify worktrees in this case by\nspecifying 'project0/foo', 'project1/foo'... Granted it's not fun to\ntype all that when 'project0/foo' is something long, and bash\ncompletion probably does not help much either.\n\nNote that we may need a unique name elsewhere too, e.g.\nrefs/worktrees/xyz (even though we haven't settled on this yet). Then\nxyz would be more exposed to the user and an easily recognizable name\nwould be a good thing.\n-- \nDuy\n"},{"id":"291746","messageId":"20160719184510.GA28551@kwain","threadId":"42878","inReplyTo":"xmqq7fchh5bo.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] worktree: add: introduce the --name option","fromName":"Antoine Tenart","fromEmail":"antoine.tenart@ack.tf","sentAt":"2016-07-19T18:45:10Z","receivedAt":"2016-07-19T18:45:18Z","isPatch":true,"sender":{"key":"antoine.tenart@ack.tf","avatar":null},"body":"Hi,\n\nOn Tue, Jul 19, 2016 at 11:04:59AM -0700, Junio C Hamano wrote:\n> \n> > Adds a --name option allowing to specify the name of a worktree when\n> > creating it. This allows to have multiple worktrees in directories\n> > having the same name (e.g. project0/foo, project1/foo etc...). This\n> > commit keeps the previous behaviour by making it the default value, i.e.\n> > by using $(basename ) as the worktree name when the --name option\n> > isn't used.\n\n[...]\n\n> Hmm, is this related to an earlier discussion\n> \n> https://public-inbox.org/git/20160625051548.95564-1-barret%40brennie.ca/\n> \n> in any way, or is it an independent invention?\n\nCompletely independent. I made a quick search before doing this... too\nquick :-)\n\n> The conclusion of that discussion thread was roughly \"users\n> shouldn't even _care_ about the name, and if they have to use name\n> to identify the worktrees to do certain things right now, reducing\n> the need for such 'certain things', not making it easy to give a\n> user-defined name to a worktree, is the way to go\", IIRC.\n\nI agree that users shouldn't have to deal with this in most cases, and\nthat's still the default behaviour with this patch. But some use cases\nrequire to change this default name: I use the same repository for each\nof my projects using the Linux kernel while working on them in parallel.\nSo I end up with something like: project1/linux, project2/linux etc...\nwhere other names than 'linux' in each project directory wouldn't really\nmake sense.\n\nBeing able to manually define the name can also be useful in some (rare)\ncases, where you reorganize your project directory tree. But that's not\na strong argument for adding this option :-)\n\nThere might be other solutions, so I'm open for discussion. I just find\nthis not-that-magic solution useful.\n\nThanks!\n\n-- \nAntoine\n"},{"id":"291748","messageId":"CAPig+cQ5eGoNFa90__ay+Y7AMP5Zd1VUDXWFCfU1-XX3oEYAkg@mail.gmail.com","threadId":"42878","inReplyTo":"xmqq7fchh5bo.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] worktree: add: introduce the --name option","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2016-07-19T18:52:42Z","receivedAt":"2016-07-19T18:52:47Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Tue, Jul 19, 2016 at 2:04 PM, Junio C Hamano wrote:\n> Antoine Tenart writes:\n>> Adds a --name option allowing to specify the name of a worktree when\n>> creating it. This allows to have multiple worktrees in directories\n>> having the same name (e.g. project0/foo, project1/foo etc...). This\n>> commit keeps the previous behaviour by making it the default value, i.e.\n>> by using $(basename ) as the worktree name when the --name option\n>> isn't used.\n>\n> Hmm, is this related to an earlier discussion\n>\n> https://public-inbox.org/git/20160625051548.95564-1-barret%40brennie.ca/\n>\n> in any way, or is it an independent invention?\n>\n> The conclusion of that discussion thread was roughly \"users\n> shouldn't even _care_ about the name, and if they have to use name\n> to identify the worktrees to do certain things right now, reducing\n> the need for such 'certain things', not making it easy to give a\n> user-defined name to a worktree, is the way to go\", IIRC.\n\nYes, that's correct. The discussion wandered a bit before starting to\nconverge at [1] and concluding at [2].\n\n[1]: https://public-inbox.org/git/CAPig%2BcRNUZZBw%3DF-Q2f3Ehc-8T2iBp4kvDusNRGv4ea5nihQVQ%40mail.gmail.com/\n[2]: https://public-inbox.org/git/CAPig%2BcSEwib1iFyWE5h8-qTbsAC%2BzsaSDSYQnv6otWoOOjWAeA%40mail.gmail.com/\n"},{"id":"291750","messageId":"20160719185452.GB28551@kwain","threadId":"42878","inReplyTo":"CACsJy8BDRPK2UKxoMat3i2HL38+KFqw2Qfet2Bev26HXRM-BWA@mail.gmail.com","subject":"Re: [PATCH] worktree: add: introduce the --name option","fromName":"Antoine Tenart","fromEmail":"antoine.tenart@ack.tf","sentAt":"2016-07-19T18:54:52Z","receivedAt":"2016-07-19T18:54:59Z","isPatch":true,"sender":{"key":"antoine.tenart@ack.tf","avatar":null},"body":"On Tue, Jul 19, 2016 at 08:23:58PM +0200, Duy Nguyen wrote:\n> On Tue, Jul 19, 2016 at 8:04 PM, Junio C Hamano wrote:\n> \n> 080739b (worktree.c: find_worktree() search by path suffix -\n> 2016-06-13) from 'next' should help identify worktrees in this case by\n> specifying 'project0/foo', 'project1/foo'... Granted it's not fun to\n> type all that when 'project0/foo' is something long, and bash\n> completion probably does not help much either.\n\nSo with this I'll be able to create new worktrees, using paths having\nthe same basename, but in different let's say \"project directories\"?\n\n> Note that we may need a unique name elsewhere too, e.g.\n> refs/worktrees/xyz (even though we haven't settled on this yet). Then\n> xyz would be more exposed to the user and an easily recognizable name\n> would be a good thing.\n\nHaving a recognisable name surely is a good thing, when performing some\n(rare) manual operations. Like moving a worktree (or is there a command\nfor this?)\n\nThanks,\n\n-- \nAntoine\n"},{"id":"291753","messageId":"CACsJy8AkpBmNS0nOoKX7PUYhp9kKgvH=K2gpCnq+sR++ZmDAgQ@mail.gmail.com","threadId":"42878","inReplyTo":"20160719185452.GB28551@kwain","subject":"Re: [PATCH] worktree: add: introduce the --name option","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-07-19T19:04:11Z","receivedAt":"2016-07-19T19:06:05Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Jul 19, 2016 at 8:54 PM, Antoine Tenart wrote:\n> On Tue, Jul 19, 2016 at 08:23:58PM +0200, Duy Nguyen wrote:\n>> On Tue, Jul 19, 2016 at 8:04 PM, Junio C Hamano wrote:\n>>\n>> 080739b (worktree.c: find_worktree() search by path suffix -\n>> 2016-06-13) from 'next' should help identify worktrees in this case by\n>> specifying 'project0/foo', 'project1/foo'... Granted it's not fun to\n>> type all that when 'project0/foo' is something long, and bash\n>> completion probably does not help much either.\n>\n> So with this I'll be able to create new worktrees, using paths having\n> the same basename, but in different let's say \"project directories\"?\n\nWell, internal name is still out of your control, but if you want to\ndo something to a worktree you can say \"do project0/foo\". With 'next'\nthose verbs can be lock and unlock. We probably can make 'worktree\nlist' take filter and show just one worktree (and just add \"git\nworktree show\" for that).\n\n>> Note that we may need a unique name elsewhere too, e.g.\n>> refs/worktrees/xyz (even though we haven't settled on this yet). Then\n>> xyz would be more exposed to the user and an easily recognizable name\n>> would be a good thing.\n>\n> Having a recognisable name surely is a good thing, when performing some\n> (rare) manual operations.\n\nWhat I had in mind was \"git log --decorate=more-than-full\", foo/HEAD\nand foo1/HEAD\ndo not look as good as project0/HEAD and project1/HEAD (*)\n\n> Like moving a worktree (or is there a command for this?)\n\nDon't touch it. I've been waiting patiently for that patch series to\nbe reviewed :)\n-- \nDuy\n"},{"id":"291755","messageId":"xmqqh9blfntw.fsf@gitster.mtv.corp.google.com","threadId":"42878","inReplyTo":"20160719184510.GA28551@kwain","subject":"Re: [PATCH] worktree: add: introduce the --name option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-07-19T19:08:11Z","receivedAt":"2016-07-19T19:08:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Antoine Tenart writes:\n\n> Being able to manually define the name can also be useful in some (rare)\n> cases, where you reorganize your project directory tree. But that's not\n> a strong argument for adding this option :-)\n\nContinuing the rationale that rejected the topic from the earlier\ndiscussion thread, the above is like saying that we should expose\ninode number more to the users and and allow users to tell a\nspecific inode number to use when creating an entry in a directory,\nwhich would allow users to edit the directory with binary editor and\nreplace the entry with the same inode number to move or rename the\npath. The discussion considers that the \"name\" is an implementation\ndetail of the worktree subsystem, like inode number is for a\nfilesystem implementation. A proper solution would be to invent\n\"mv\" command ;-).\n\n"},{"id":"291759","messageId":"CAPig+cSWQDJzDKN30Ho-ziDH-Wyg5pPx-WMeQ4WCPdy7PZJkVA@mail.gmail.com","threadId":"42878","inReplyTo":"CACsJy8AkpBmNS0nOoKX7PUYhp9kKgvH=K2gpCnq+sR++ZmDAgQ@mail.gmail.com","subject":"Re: [PATCH] worktree: add: introduce the --name option","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2016-07-19T19:21:20Z","receivedAt":"2016-07-19T19:21:39Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Tue, Jul 19, 2016 at 3:04 PM, Duy Nguyen wrote:\n> On Tue, Jul 19, 2016 at 8:54 PM, Antoine Tenart wrote:\n>> Like moving a worktree (or is there a command for this?)\n>\n> Don't touch it. I've been waiting patiently for that patch series to\n> be reviewed :)\n\nFor newcomers, \"that patch series\" refers to [1].\n\nIf it's any consolation (probably not), I'm still trying to find an\nopportunity to review it, however, my computer time is severely\nlimited these days. In fact, I'm so far behind, I still haven't\nreviewed the worktree-lock re-roll (which probably has already hit\n'master').\n\n[1]: http://thread.gmane.org/gmane.comp.version-control.git/298194\n"},{"id":"291762","messageId":"20160719193351.GC28551@kwain","threadId":"42878","inReplyTo":"xmqqh9blfntw.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] worktree: add: introduce the --name option","fromName":"Antoine Tenart","fromEmail":"antoine.tenart@ack.tf","sentAt":"2016-07-19T19:33:51Z","receivedAt":"2016-07-19T19:34:00Z","isPatch":true,"sender":{"key":"antoine.tenart@ack.tf","avatar":null},"body":"On Tue, Jul 19, 2016 at 12:08:11PM -0700, Junio C Hamano wrote:\n> Antoine Tenart writes:\n> \n> > Being able to manually define the name can also be useful in some (rare)\n> > cases, where you reorganize your project directory tree. But that's not\n> > a strong argument for adding this option :-)\n> \n> Continuing the rationale that rejected the topic from the earlier\n> discussion thread, the above is like saying that we should expose\n> inode number more to the users and and allow users to tell a\n> specific inode number to use when creating an entry in a directory,\n> which would allow users to edit the directory with binary editor and\n> replace the entry with the same inode number to move or rename the\n> path. The discussion considers that the \"name\" is an implementation\n> detail of the worktree subsystem, like inode number is for a\n> filesystem implementation. A proper solution would be to invent\n> \"mv\" command ;-).\n\nHehe :-)\n\n-- \nAntoine\n"},{"id":"291764","messageId":"20160719193523.GD28551@kwain","threadId":"42878","inReplyTo":"CACsJy8AkpBmNS0nOoKX7PUYhp9kKgvH=K2gpCnq+sR++ZmDAgQ@mail.gmail.com","subject":"Re: [PATCH] worktree: add: introduce the --name option","fromName":"Antoine Tenart","fromEmail":"antoine.tenart@ack.tf","sentAt":"2016-07-19T19:35:23Z","receivedAt":"2016-07-19T19:35:37Z","isPatch":true,"sender":{"key":"antoine.tenart@ack.tf","avatar":null},"body":"On Tue, Jul 19, 2016 at 09:04:11PM +0200, Duy Nguyen wrote:\n> On Tue, Jul 19, 2016 at 8:54 PM, Antoine Tenart wrote:\n> > On Tue, Jul 19, 2016 at 08:23:58PM +0200, Duy Nguyen wrote:\n> >> On Tue, Jul 19, 2016 at 8:04 PM, Junio C Hamano wrote:\n> >>\n> >> 080739b (worktree.c: find_worktree() search by path suffix -\n> >> 2016-06-13) from 'next' should help identify worktrees in this case by\n> >> specifying 'project0/foo', 'project1/foo'... Granted it's not fun to\n> >> type all that when 'project0/foo' is something long, and bash\n> >> completion probably does not help much either.\n> >\n> > So with this I'll be able to create new worktrees, using paths having\n> > the same basename, but in different let's say \"project directories\"?\n> \n> Well, internal name is still out of your control, but if you want to\n> do something to a worktree you can say \"do project0/foo\". With 'next'\n> those verbs can be lock and unlock. We probably can make 'worktree\n> list' take filter and show just one worktree (and just add \"git\n> worktree show\" for that).\n\nHmm, so if I understand correctly my use case still won't be supported,\nas adding a new worktree with the same basename will fail. Or did I miss\nsomething?\n\n-- \nAntoine\n"},{"id":"291789","messageId":"20160720064120.GE28551@kwain","threadId":"42878","inReplyTo":"CAPig+cQ5eGoNFa90__ay+Y7AMP5Zd1VUDXWFCfU1-XX3oEYAkg@mail.gmail.com","subject":"Re: [PATCH] worktree: add: introduce the --name option","fromName":"Antoine Tenart","fromEmail":"antoine.tenart@ack.tf","sentAt":"2016-07-20T06:41:20Z","receivedAt":"2016-07-20T06:41:33Z","isPatch":true,"sender":{"key":"antoine.tenart@ack.tf","avatar":null},"body":"Hello Eric,\n\nOn Tue, Jul 19, 2016 at 02:52:42PM -0400, Eric Sunshine wrote:\n> On Tue, Jul 19, 2016 at 2:04 PM, Junio C Hamano wrote:\n> > Antoine Tenart writes:\n> >> Adds a --name option allowing to specify the name of a worktree when\n> >> creating it. This allows to have multiple worktrees in directories\n> >> having the same name (e.g. project0/foo, project1/foo etc...). This\n> >> commit keeps the previous behaviour by making it the default value, i.e.\n> >> by using $(basename ) as the worktree name when the --name option\n> >> isn't used.\n> >\n> > Hmm, is this related to an earlier discussion\n> >\n> > https://public-inbox.org/git/20160625051548.95564-1-barret%40brennie.ca/\n> >\n> > in any way, or is it an independent invention?\n> >\n> > The conclusion of that discussion thread was roughly \"users\n> > shouldn't even _care_ about the name, and if they have to use name\n> > to identify the worktrees to do certain things right now, reducing\n> > the need for such 'certain things', not making it easy to give a\n> > user-defined name to a worktree, is the way to go\", IIRC.\n> \n> Yes, that's correct. The discussion wandered a bit before starting to\n> converge at [1] and concluding at [2].\n> \n> [1]: https://public-inbox.org/git/CAPig%2BcRNUZZBw%3DF-Q2f3Ehc-8T2iBp4kvDusNRGv4ea5nihQVQ%40mail.gmail.com/\n> [2]: https://public-inbox.org/git/CAPig%2BcSEwib1iFyWE5h8-qTbsAC%2BzsaSDSYQnv6otWoOOjWAeA%40mail.gmail.com/\n\nThanks for the links, I've had a look at the discussion. The problem\nthat raised it was a bit different: it was about reorganizing projects\nand directory trees, no about creating a new worktree with the same\nbasename as an existing one. I've also had a look at 080739b,\nintroducing find_worktree(), but I don't think that would solve the\nissue either.\n\nSo we've left with two solutions: being able to specify the worktree\nname or having an arbitrary ID (plus some modifications to `git worktree\nlist`) as you proposed. I guess you prefer the later solution. Is there\nany plan to do this, or anything in progress?\n\nThanks,\n\n-- \nAntoine\n"},{"id":"291813","messageId":"CACsJy8AatsjV7L6u6oA5xx+=K9hc9pjYTm_-XxxHHQ8aG9HyeQ@mail.gmail.com","threadId":"42878","inReplyTo":"20160719193523.GD28551@kwain","subject":"Re: [PATCH] worktree: add: introduce the --name option","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-07-20T14:54:40Z","receivedAt":"2016-07-20T14:55:44Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Jul 19, 2016 at 9:35 PM, Antoine Tenart wrote:\n> On Tue, Jul 19, 2016 at 09:04:11PM +0200, Duy Nguyen wrote:\n>> On Tue, Jul 19, 2016 at 8:54 PM, Antoine Tenart wrote:\n>> > On Tue, Jul 19, 2016 at 08:23:58PM +0200, Duy Nguyen wrote:\n>> >> On Tue, Jul 19, 2016 at 8:04 PM, Junio C Hamano wrote:\n>> >>\n>> >> 080739b (worktree.c: find_worktree() search by path suffix -\n>> >> 2016-06-13) from 'next' should help identify worktrees in this case by\n>> >> specifying 'project0/foo', 'project1/foo'... Granted it's not fun to\n>> >> type all that when 'project0/foo' is something long, and bash\n>> >> completion probably does not help much either.\n>> >\n>> > So with this I'll be able to create new worktrees, using paths having\n>> > the same basename, but in different let's say \"project directories\"?\n>>\n>> Well, internal name is still out of your control, but if you want to\n>> do something to a worktree you can say \"do project0/foo\". With 'next'\n>> those verbs can be lock and unlock. We probably can make 'worktree\n>> list' take filter and show just one worktree (and just add \"git\n>> worktree show\" for that).\n>\n> Hmm, so if I understand correctly my use case still won't be supported,\n> as adding a new worktree with the same basename will fail. Or did I miss\n> something?\n\nHm... _what_ fails? If you create two worktrees project0/foo and\nproject1/foo, you'll get .git/worktrees/foo and .git/worktrees/foo1\nbut worktree creation should succeed both times. As long as you don't\nhave to look into .git/worktrees/ everything should be fine, you won't\nsee foo vs foo1.\n\nIf you absolutely have to, I'm thinking of \"git --rev-parse\n--worktree= --git-dir\" (or something similar) that will give you\n$GIT_DIR to a specific worktree (e.g. .git/worktrees/foo or\n.git/worktrees/foo1). Then you can specify \"git rev-parse\n--worktree=project0/foo --git-dir\" and still don't have to see foo vs\nfoo1.\n-- \nDuy\n"},{"id":"291831","messageId":"20160720161225.GA23406@kwain","threadId":"42878","inReplyTo":"CACsJy8AatsjV7L6u6oA5xx+=K9hc9pjYTm_-XxxHHQ8aG9HyeQ@mail.gmail.com","subject":"Re: [PATCH] worktree: add: introduce the --name option","fromName":"Antoine Tenart","fromEmail":"antoine.tenart@ack.tf","sentAt":"2016-07-20T16:12:25Z","receivedAt":"2016-07-20T16:12:39Z","isPatch":true,"sender":{"key":"antoine.tenart@ack.tf","avatar":null},"body":"On Wed, Jul 20, 2016 at 04:54:40PM +0200, Duy Nguyen wrote:\n> On Tue, Jul 19, 2016 at 9:35 PM, Antoine Tenart wrote:\n> >\n> > Hmm, so if I understand correctly my use case still won't be supported,\n> > as adding a new worktree with the same basename will fail. Or did I miss\n> > something?\n> \n> Hm... _what_ fails? If you create two worktrees project0/foo and\n> project1/foo, you'll get .git/worktrees/foo and .git/worktrees/foo1\n> but worktree creation should succeed both times. As long as you don't\n> have to look into .git/worktrees/ everything should be fine, you won't\n> see foo vs foo1.\n\nYou're right, I don't know why I was sure this wasn't working... Sorry\nfor the noise :-)\n\n-- \nAntoine\n"}]}