{"thread":{"id":"42709","subject":"[PATCH] builtin/worktree.c: add option for setting worktree name","startedAt":"2016-06-25T05:23:31Z","lastAt":"2016-06-29T04:45:25Z","messageCount":16,"participants":["Barret Rennie","Junio C Hamano","Johannes Sixt","Eric Sunshine"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"290094","messageId":"20160625051548.95564-1-barret@brennie.ca","threadId":"42709","inReplyTo":null,"subject":"[PATCH] builtin/worktree.c: add option for setting worktree name","fromName":"Barret Rennie","fromEmail":"barret@brennie.ca","sentAt":"2016-06-25T05:15:48Z","receivedAt":"2016-06-25T05:23:31Z","isPatch":true,"sender":{"key":"barret@brennie.ca","avatar":"https://gravatar.com/avatar/9da1b9739ac5719000cbe46c5535ead1e58078d96da500f58b239a7edb4b2e00?d=mp&s=160"},"body":"Add the --name parameter to git worktree add that allows the user to set\nthe name of the created worktree directory. A worktree must not already\nexist with the current name or creation will fail.\n\nSigned-off-by: Barret Rennie \n---\n Documentation/git-worktree.txt | 6 +++++-\n builtin/worktree.c | 24 ++++++++++++++++++------\n t/t2025-worktree-add.sh | 16 ++++++++++++++++\n 3 files changed, 39 insertions(+), 7 deletions(-)\n\ndiff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt\nindex 23d8d2a..2af0ee4 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 prune' [-n] [-v] [--expire ]\n 'git worktree list' [--porcelain]\n \n@@ -88,6 +88,10 @@ OPTIONS\n \tWith `add`, detach HEAD in the new working tree. See \"DETACHED HEAD\"\n \tin linkgit:git-checkout[1].\n \n+--name::\n+\tSet the name for the worktree. If there is already a worktree with this\n+\tname, the command will fail.\n+\n --[no-]checkout::\n \tBy default, `add` checks out ``, however, `--no-checkout` can\n \tbe used to suppress checkout in order to make customizations,\ndiff --git a/builtin/worktree.c b/builtin/worktree.c\nindex e3199a2..ed071b2 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,19 +213,29 @@ 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+\tif (opts->name) {\n+\t\tname = opts->name;\n+\t\tlen = strlen(name);\n+\t} else {\n+\t\tname = worktree_basename(path, &len);\n+\t}\n+\n \tstrbuf_addstr(&sb_repo,\n \t\t git_path(\"worktrees/%.*s\", (int)(path + len - name), name));\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 \t\t\t sb_repo.buf);\n-\twhile (!stat(sb_repo.buf, &st)) {\n-\t\tcounter++;\n-\t\tstrbuf_setlen(&sb_repo, len);\n-\t\tstrbuf_addf(&sb_repo, \"%d\", counter);\n+\n+\tif (!opts->name) {\n+\t\twhile (!stat(sb_repo.buf, &st)) {\n+\t\t\tcounter++;\n+\t\t\tstrbuf_setlen(&sb_repo, len);\n+\t\t\tstrbuf_addf(&sb_repo, \"%d\", counter);\n+\t\t}\n+\t\tname = strrchr(sb_repo.buf, '/') + 1;\n \t}\n-\tname = strrchr(sb_repo.buf, '/') + 1;\n \n \tjunk_pid = getpid();\n \tatexit(remove_junk);\n@@ -326,6 +337,7 @@ static int add(int ac, const char **av, const char *prefix)\n \t\t\t N_(\"create or reset a branch\")),\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_STRING(0, \"name\", &opts.name, N_(\"name\"), N_(\"set name for working tree\")),\n \t\tOPT_END()\n \t};\n \ndiff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh\nindex 4bcc335..9abcf8e 100755\n--- a/t/t2025-worktree-add.sh\n+++ b/t/t2025-worktree-add.sh\n@@ -63,6 +63,22 @@ test_expect_success '\"add\" worktree' '\n \t)\n '\n \n+test_expect_success '\"add\" worktree with name' '\n+\tgit worktree add --detach --name custom-name another-worktree master &&\n+\t(\n+\t\tcd here &&\n+\t\ttest_cmp ../init.t init.t\n+\t) &&\n+\t(\n+\t\tcd .git/worktrees &&\n+\t\ttest -d custom-name\n+\t)\n+'\n+\n+test_expect_success '\"add\" worktree with name that already exists' '\n+\ttest_must_fail git worktree add --name custom-name --detach yet-another-worktree master\n+'\n+\n test_expect_success '\"add\" worktree from a subdir' '\n \t(\n \t\tmkdir sub &&\n-- \n2.9.0\n\n"},{"id":"290109","messageId":"xmqq60sxeqr4.fsf@gitster.mtv.corp.google.com","threadId":"42709","inReplyTo":"20160625051548.95564-1-barret@brennie.ca","subject":"Re: [PATCH] builtin/worktree.c: add option for setting worktree name","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-06-25T06:17:51Z","receivedAt":"2016-06-25T06:17:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Barret Rennie writes:\n\n> Add the --name parameter to git worktree add that allows the user to set\n> the name of the created worktree directory. A worktree must not already\n> exist with the current name or creation will fail.\n\nHmph. This strongly smells like \"because we can add this feature\",\nnot \"because we need to add this feature\".\n\nWhat problem does it solve? Please do not give me \"currently we\ncannot give a name and instead live with the automatically given\none, and with this patch we can give arbitrary name\" as the answer.\nThat is what I called \"because we can\". Why is it bad that you have\nto live with the name automatically given to your new worktree?\n"},{"id":"290110","messageId":"58A7F9CA-05A1-4BD1-A664-5B8302BFDE2F@brennie.ca","threadId":"42709","inReplyTo":"xmqq60sxeqr4.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] builtin/worktree.c: add option for setting worktree name","fromName":"Barret Rennie","fromEmail":"barret@brennie.ca","sentAt":"2016-06-25T06:28:53Z","receivedAt":"2016-06-25T06:29:01Z","isPatch":true,"sender":{"key":"barret@brennie.ca","avatar":"https://gravatar.com/avatar/9da1b9739ac5719000cbe46c5535ead1e58078d96da500f58b239a7edb4b2e00?d=mp&s=160"},"body":"This is really to scratch an itch I have when I break my worktrees and can’t figure out which worktree dir is the one I’ve broken. For example, I organize my code as follows:\n\nprojects/reviewboard/branches//src/\n\tdjango/\n\tdjblets/ \n\treviewboard/\n\nfor each release branch I maintain (4 or 5 of them), where each of the above is a worktree checkout of the correct branch. This is so I have all my dependencies for the project at the right development version.\n\nHowever, when I inevitably break a worktree for, e.g., Review Board, I have to figure out which of reviewboard, reviewboard1, reviewboard2, etc. it is that I’ve broken, instead of being able to just go into the worktree named for the release branch.\n\nHope this clarifies things.\n\n> On Jun 25, 2016, at 12:17 AM, Junio C Hamano wrote:\n> \n> Barret Rennie writes:\n> \n>> Add the --name parameter to git worktree add that allows the user to set\n>> the name of the created worktree directory. A worktree must not already\n>> exist with the current name or creation will fail.\n> \n> Hmph. This strongly smells like \"because we can add this feature\",\n> not \"because we need to add this feature\".\n> \n> What problem does it solve? Please do not give me \"currently we\n> cannot give a name and instead live with the automatically given\n> one, and with this patch we can give arbitrary name\" as the answer.\n> That is what I called \"because we can\". Why is it bad that you have\n> to live with the name automatically given to your new worktree?\n\n"},{"id":"290114","messageId":"576E2FA9.7070008@kdbg.org","threadId":"42709","inReplyTo":"20160625051548.95564-1-barret@brennie.ca","subject":"Re: [PATCH] builtin/worktree.c: add option for setting worktree name","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2016-06-25T07:15:53Z","receivedAt":"2016-06-25T07:16:02Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 25.06.2016 um 07:15 schrieb Barret Rennie:\n> +--name::\n> +\tSet the name for the worktree. If there is already a worktree with this\n\nWhat is \"the name for the worktree\"? Is it the directory where it lives \nin? Is it how it is listed with 'git worktree list'?\n\nHow is --name different from the argument?\n\n-- Hannes\n\n"},{"id":"290115","messageId":"6FF436EC-65BE-472A-A347-1E0DCD7526AF@brennie.ca","threadId":"42709","inReplyTo":"576E2FA9.7070008@kdbg.org","subject":"Re: [PATCH] builtin/worktree.c: add option for setting worktree name","fromName":"Barret Rennie","fromEmail":"barret@brennie.ca","sentAt":"2016-06-25T07:29:49Z","receivedAt":"2016-06-25T07:29:56Z","isPatch":true,"sender":{"key":"barret@brennie.ca","avatar":"https://gravatar.com/avatar/9da1b9739ac5719000cbe46c5535ead1e58078d96da500f58b239a7edb4b2e00?d=mp&s=160"},"body":"> What is \"the name for the worktree\"? Is it the directory where it lives in?\n>Is it how it is listed with 'git worktree list'?\n\nThe name of the worktree is the name of the created directory in\n`.git/worktrees`.\n\n> How is --name different from the argument?\n\nCurrently, if you run:\n\t\n\tgit worktree add /my/worktree/checkout \n\nyou get a worktree \"named\" checkout, i.e., `.git/worktrees/checkout`. The\nidea with this patch is to allow you use a more specific name when you would\notherwise have mulitiple worktrees of the form `checkout`, `checkout1`, etc.\n\nThat is, you could do\n\n\tgit worktree add --name branch1 /worktrees/branch1/src branch1\n\tgit worktree add --name branch2 /worktrees/branch2/src branch2\n\tgit worktree add --name branch3 /worktrees/branch3/src branch3\n\nand have `.git/worktrees/branch1`, `.git/worktrees/branch2` and\n`.git/worktrees/branch3` instead of `.git/worktrees/src`,\n`.git/worktrees/src1`, `.git/worktrees/src2`. That way, it becomes more clear\nwhen poking inside `.git/worktrees` which directory points to which checkout.\n\nPerhaps \"worktree name\" isn't the most clear nomenclature for this feature.\nWould \"worktree directory name\" be better?\n"},{"id":"290116","messageId":"1FEF5F90-6534-4D91-B27C-16FE6D16EC3F@brennie.ca","threadId":"42709","inReplyTo":"576E2FA9.7070008@kdbg.org","subject":"Re: [PATCH] builtin/worktree.c: add option for setting worktree name","fromName":"Barret Rennie","fromEmail":"barret@brennie.ca","sentAt":"2016-06-25T07:29:49Z","receivedAt":"2016-06-25T07:30:00Z","isPatch":true,"sender":{"key":"barret@brennie.ca","avatar":"https://gravatar.com/avatar/9da1b9739ac5719000cbe46c5535ead1e58078d96da500f58b239a7edb4b2e00?d=mp&s=160"},"body":"> What is \"the name for the worktree\"? Is it the directory where it lives in?\n>Is it how it is listed with 'git worktree list'?\n\nThe name of the worktree is the name of the created directory in\n`.git/worktrees`.\n\n> How is --name different from the argument?\n\nCurrently, if you run:\n\t\n\tgit worktree add /my/worktree/checkout \n\nyou get a worktree \"named\" checkout, i.e., `.git/worktrees/checkout`. The\nidea with this patch is to allow you use a more specific name when you would\notherwise have mulitiple worktrees of the form `checkout`, `checkout1`, etc.\n\nThat is, you could do\n\n\tgit worktree add --name branch1 /worktrees/branch1/src branch1\n\tgit worktree add --name branch2 /worktrees/branch2/src branch2\n\tgit worktree add --name branch3 /worktrees/branch3/src branch3\n\nand have `.git/worktrees/branch1`, `.git/worktrees/branch2` and\n`.git/worktrees/branch3` instead of `.git/worktrees/src`,\n`.git/worktrees/src1`, `.git/worktrees/src2`. That way, it becomes more clear\nwhen poking inside `.git/worktrees` which directory points to which checkout.\n\nPerhaps \"worktree name\" isn't the most clear nomenclature for this feature.\nWould \"worktree directory name\" be better?\n"},{"id":"290117","messageId":"77A9E927-84CD-40F0-B7E1-077EC8B70313@brennie.ca","threadId":"42709","inReplyTo":"576E2FA9.7070008@kdbg.org","subject":"Re: [PATCH] builtin/worktree.c: add option for setting worktree name","fromName":"Barret Rennie","fromEmail":"barret@brennie.ca","sentAt":"2016-06-25T07:32:31Z","receivedAt":"2016-06-25T07:33:06Z","isPatch":true,"sender":{"key":"barret@brennie.ca","avatar":"https://gravatar.com/avatar/9da1b9739ac5719000cbe46c5535ead1e58078d96da500f58b239a7edb4b2e00?d=mp&s=160"},"body":"Sorry for replying to that message twice. I hit a bug in Apple Mail.\n\n--Barret\n"},{"id":"290150","messageId":"xmqq1t3ldpdl.fsf@gitster.mtv.corp.google.com","threadId":"42709","inReplyTo":"1FEF5F90-6534-4D91-B27C-16FE6D16EC3F@brennie.ca","subject":"Re: [PATCH] builtin/worktree.c: add option for setting worktree name","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-06-25T19:45:10Z","receivedAt":"2016-06-25T19:45:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Barret Rennie writes:\n\n>> What is \"the name for the worktree\"? Is it the directory where it lives in?\n>>Is it how it is listed with 'git worktree list'?\n>\n> The name of the worktree is the name of the created directory in\n> `.git/worktrees`.\n>\n>> How is --name different from the argument?\n>\n> Currently, if you run:\n> \t\n> \tgit worktree add /my/worktree/checkout \n>\n> you get a worktree \"named\" checkout, i.e., `.git/worktrees/checkout`. The\n> idea with this patch is to allow you use a more specific name when you would\n> otherwise have mulitiple worktrees of the form `checkout`, `checkout1`, etc.\n>\n> That is, you could do\n>\n> \tgit worktree add --name branch1 /worktrees/branch1/src branch1\n> \tgit worktree add --name branch2 /worktrees/branch2/src branch2\n> \tgit worktree add --name branch3 /worktrees/branch3/src branch3\n>\n> and have `.git/worktrees/branch1`, `.git/worktrees/branch2` and\n> `.git/worktrees/branch3` instead of `.git/worktrees/src`,\n> `.git/worktrees/src1`, `.git/worktrees/src2`. That way, it becomes more clear\n> when poking inside `.git/worktrees` which directory points to which checkout.\n\nThat is a way better justification of \"why we need to use a custom\nname, not the default one\" than the previous \"with this we can use a\ncustom name\".\n\nAs long as you can justify why having anything underneath branch$n/\nis necessary, that is. In your explanation above, it is still\nunclear why you need a checkout at /worktrees/branch$n/src/, and why\nit would not work if it is at /worktrees/branch$n/.\n\nNote that I am not saying \"there cannot be a good reason, do not add\nthis feature\" when I say \"it is unclear why\". I am encouraging you\nand others in this discussion thread to find good use cases for the\nproposed new feature and come up with materials to help improving\nthe documentation part of the patch. That way, the users with\nsimilar needs can find how the feature is supposed to be used and\nunderstand the feature better.\n\nI suspect that this new feature might be useful when two more more\ninterdependent projects (they could be organized as submodules in a\nsuperproject, but they can be independent checkouts of different\nprojects) are used together. Imagine frotz and nitfol projects, and\nwithout fancier setup to have multiple checkouts, you may be\nexpected (by these two projects) to check them out like so:\n\n $top/frotz/\n $top/libs/nitfol/\n\nwhere $top can be anywhere but to clarify the line of thought, lets\npick a concrete place, say $HOME/xyzzy. So without worktrees, you\nwould have\n\n $HOME/xyzzy/frotz\n $HOME/xyzzy/libs/nitfol\n\nNow, if you do the worktree, you may still want the relative\nstructure between these two, i.e. if you want to work on two\ndifferent branch combinations of the whole thing, you would want to\ndo this:\n\n $HOME/xyzzy-1/frotz - borrow from $HOME/xyzzy/frotz\n $HOME/xyzzy-1/libs/nitfol - likewise for nitfol\n\n $HOME/xyzzy-2/frotz - borrow from $HOME/xyzzy/frotz\n $HOME/xyzzy-2/libs/nitfol - likewise for nitfol\n\nwhere xyzzy-$n may be for topic-$n branch both in frotz and nitfol.\n\nAnd explained that way, it becomes clearer that you would want to\nname $HOME/xyzzy-1/frotz worktree after \"topic-1\", not the default\nname you would get \"frotz\" (because the default gives you the leaf\nlevel name of the newly created worktree).\n\nAfter the discussion above (which may or may not match what you\nraised this topic for), I think a feature to let you override the\ndefault name makes sense.\n\nIt just needs to be explained better to help the users when the\nfeature eventually becomes part of Git. Also, others (especially\nDuy) may have even better ideas (e.g. instead of having to always\nuse --name to give custom name for all worktrees, set a \"hint\" just\nonce to help the logic that comes up with the default name give a\nbetter name), so while the feature may be desirable, your exact\nimplementation may or may not be what we eventually want to adopt.\n\nThanks.\n\n\n"},{"id":"290152","messageId":"15A0703E-92CD-4736-AF7D-5E809D7CEDF7@brennie.ca","threadId":"42709","inReplyTo":"xmqq1t3ldpdl.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] builtin/worktree.c: add option for setting worktree name","fromName":"Barret Rennie","fromEmail":"barret@brennie.ca","sentAt":"2016-06-25T20:19:54Z","receivedAt":"2016-06-25T20:20:11Z","isPatch":true,"sender":{"key":"barret@brennie.ca","avatar":"https://gravatar.com/avatar/9da1b9739ac5719000cbe46c5535ead1e58078d96da500f58b239a7edb4b2e00?d=mp&s=160"},"body":"\n> On Jun 25, 2016, at 1:45 PM, Junio C Hamano wrote:\n> \n> Barret Rennie writes:\n> \n>>> What is \"the name for the worktree\"? Is it the directory where it lives in?\n>>> Is it how it is listed with 'git worktree list'?\n>> \n>> The name of the worktree is the name of the created directory in\n>> `.git/worktrees`.\n>> \n>>> How is --name different from the argument?\n>> \n>> Currently, if you run:\n>> \t\n>> \tgit worktree add /my/worktree/checkout \n>> \n>> you get a worktree \"named\" checkout, i.e., `.git/worktrees/checkout`. The\n>> idea with this patch is to allow you use a more specific name when you would\n>> otherwise have mulitiple worktrees of the form `checkout`, `checkout1`, etc.\n>> \n>> That is, you could do\n>> \n>> \tgit worktree add --name branch1 /worktrees/branch1/src branch1\n>> \tgit worktree add --name branch2 /worktrees/branch2/src branch2\n>> \tgit worktree add --name branch3 /worktrees/branch3/src branch3\n>> \n>> and have `.git/worktrees/branch1`, `.git/worktrees/branch2` and\n>> `.git/worktrees/branch3` instead of `.git/worktrees/src`,\n>> `.git/worktrees/src1`, `.git/worktrees/src2`. That way, it becomes more clear\n>> when poking inside `.git/worktrees` which directory points to which checkout.\n> \n> That is a way better justification of \"why we need to use a custom\n> name, not the default one\" than the previous \"with this we can use a\n> custom name\".\n> \n> As long as you can justify why having anything underneath branch$n/\n> is necessary, that is. In your explanation above, it is still\n> unclear why you need a checkout at /worktrees/branch$n/src/, and why\n> it would not work if it is at /worktrees/branch$n/.\n\nThat was a less-than-concrete example, I'll grant you. I do follow the method\nyou suggest below for the projects I maintain with this workflow.\n\n> \n> Note that I am not saying \"there cannot be a good reason, do not add\n> this feature\" when I say \"it is unclear why\". I am encouraging you\n> and others in this discussion thread to find good use cases for the\n> proposed new feature and come up with materials to help improving\n> the documentation part of the patch. That way, the users with\n> similar needs can find how the feature is supposed to be used and\n> understand the feature better.\n> \n> I suspect that this new feature might be useful when two more more\n> interdependent projects (they could be organized as submodules in a\n> superproject, but they can be independent checkouts of different\n> projects) are used together. Imagine frotz and nitfol projects, and\n> without fancier setup to have multiple checkouts, you may be\n> expected (by these two projects) to check them out like so:\n> \n> $top/frotz/\n> $top/libs/nitfol/\n> \n> where $top can be anywhere but to clarify the line of thought, lets\n> pick a concrete place, say $HOME/xyzzy. So without worktrees, you\n> would have\n> \n> $HOME/xyzzy/frotz\n> $HOME/xyzzy/libs/nitfol\n> \n> Now, if you do the worktree, you may still want the relative\n> structure between these two, i.e. if you want to work on two\n> different branch combinations of the whole thing, you would want to\n> do this:\n> \n> $HOME/xyzzy-1/frotz - borrow from $HOME/xyzzy/frotz\n> $HOME/xyzzy-1/libs/nitfol - likewise for nitfol\n> \n> $HOME/xyzzy-2/frotz - borrow from $HOME/xyzzy/frotz\n> $HOME/xyzzy-2/libs/nitfol - likewise for nitfol\n> \n> where xyzzy-$n may be for topic-$n branch both in frotz and nitfol.\n> \n> And explained that way, it becomes clearer that you would want to\n> name $HOME/xyzzy-1/frotz worktree after \"topic-1\", not the default\n> name you would get \"frotz\" (because the default gives you the leaf\n> level name of the newly created worktree).\n> \n> After the discussion above (which may or may not match what you\n> raised this topic for), I think a feature to let you override the\n> default name makes sense.\n> \n> It just needs to be explained better to help the users when the\n> feature eventually becomes part of Git. Also, others (especially\n> Duy) may have even better ideas (e.g. instead of having to always\n> use --name to give custom name for all worktrees, set a \"hint\" just\n> once to help the logic that comes up with the default name give a\n> better name), so while the feature may be desirable, your exact\n> implementation may or may not be what we eventually want to adopt.\n\nWould you like me to re-submit this with a more detailed\nexplanation in the commit message? Also, I agree that always having\nto use `--name` to set a custom name could be possibly cumbersome.\nAn alternate way I can think of would be to a config option such as\n`worktree.nameHint` which would let you set the kind of name you'd\nlike for your worktrees, say `default` (the current behaviour) or\n`branch` (where it would be named ).\n\nThe only issue I have with that is I maintain two projects that\nhave a dependency on the same version of a library. My current\nproject directory looks like the following:\n\nprojects/reviewboard/branches/\n\t2.5.x/\n\t\treviewboard/ # Version 2.0\n\t\tdjblets/ # Version 0.8\n\t3.0.x/\n\t\treviewboard/ # Version 3.0\n\t\tdjblets/ # Version 0.10\n\nprojects/splat/src/\n\tsplat/ # master checkout\n\tdjblets/ # Version 0.10\n\nIf we used some sort of hint system, I'd end up with two worktrees\nnamed something like `release-0.10.x` and `release-0.10.x1`, which\nis better than the current situation, but still not ideal for my\nuse case.\n\nIf someone suggests a better scheme for naming the worktrees, I'd\nbe happy to rewrite this patch to use it.\n\n> Thanks.\nThanks for reviewing.\n\n"},{"id":"290200","messageId":"xmqqshvzddet.fsf@gitster.mtv.corp.google.com","threadId":"42709","inReplyTo":"xmqq1t3ldpdl.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] builtin/worktree.c: add option for setting worktree name","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-06-26T18:15:54Z","receivedAt":"2016-06-26T18:16:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Now, if you do the worktree, you may still want the relative\n> structure between these two, i.e. if you want to work on two\n> different branch combinations of the whole thing, you would want to\n> do this:\n>\n> $HOME/xyzzy-1/frotz - borrow from $HOME/xyzzy/frotz\n> $HOME/xyzzy-1/libs/nitfol - likewise for nitfol\n>\n> $HOME/xyzzy-2/frotz - borrow from $HOME/xyzzy/frotz\n> $HOME/xyzzy-2/libs/nitfol - likewise for nitfol\n>\n> where xyzzy-$n may be for topic-$n branch both in frotz and nitfol.\n>\n> And explained that way, it becomes clearer that you would want to\n> name $HOME/xyzzy-1/frotz worktree after \"topic-1\", not the default\n> name you would get \"frotz\" (because the default gives you the leaf\n> level name of the newly created worktree).\n>\n> After the discussion above (which may or may not match what you\n> raised this topic for), I think a feature to let you override the\n> default name makes sense.\n>\n> It just needs to be explained better to help the users when the\n> feature eventually becomes part of Git. Also, others (especially\n> Duy) may have even better ideas (e.g. instead of having to always\n> use --name to give custom name for all worktrees, set a \"hint\" just\n> once to help the logic that comes up with the default name give a\n> better name), so while the feature may be desirable, your exact\n> implementation may or may not be what we eventually want to adopt.\n\nFor example, the \"frotz\" and \"nitfol\" repositories (i.e. where their\nworktrees borrow their refs and object stores from) could have a\nsingle configuration variable each, i.e.\n\n\t(in $HOME/xyzzy/frotz/.git/config)\n [worktree] location = \"~/*/frotz\"\n\n\t(in $HOME/xyzzy/libs/nitfol/.git/config)\n [worktree] location = \"~/*/libs/nitfol\"\n\nand then the user could do in each of these two repositories\n\n\t$ git -C ~/xyzzy/frotz worktree add --by-name xyzzy-1 topic-1\n\t$ git -C ~/xyzzy/lib/nitfol worktree add --by-name xyzzy-1 topic-1\n\nto get the desired layout instead.\n\nThe traditional way may be \"create one HERE\", and your patch tries\nto tweak it to \"create one at HERE with this NAME\". The above\nattempts to remove the need for specifying the exact location every\ntime a new worktree is created, and instead let you specify the\nsystematic way in which you lay out your worktrees based on their\nnames.\n\n"},{"id":"290206","messageId":"CAPig+cRNUZZBw=F-Q2f3Ehc-8T2iBp4kvDusNRGv4ea5nihQVQ@mail.gmail.com","threadId":"42709","inReplyTo":"xmqq1t3ldpdl.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] builtin/worktree.c: add option for setting worktree name","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2016-06-26T23:00:23Z","receivedAt":"2016-06-26T23:00:31Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Sat, Jun 25, 2016 at 3:45 PM, Junio C Hamano wrote:\n> [...snip...]\n> And explained that way, it becomes clearer that you would want to\n> name $HOME/xyzzy-1/frotz worktree after \"topic-1\", not the default\n> name you would get \"frotz\" (because the default gives you the leaf\n> level name of the newly created worktree).\n>\n> After the discussion above (which may or may not match what you\n> raised this topic for), I think a feature to let you override the\n> default name makes sense.\n\nOne thing which hasn't been explained, and about which I'm still\nconfused even after reading this thread in its entirety, is what\nBarret means when he says that he \"breaks\" his worktrees. What is the\nnature of this breakage? Depending upon that answer, would \"git\nrev-parse --git-dir\" be sufficient for your needs? Or, would \"git\nworktree list\" be able to give you the desired information? (As\nenvisioned, \"git worktree list\" was intended to provide much more\ninformation than it currently does, such as the .git/worktree dir\nname, and such an enhancement might be welcome.)\n"},{"id":"290218","messageId":"036C19B4-5941-43E4-AE2A-8782797D9523@brennie.ca","threadId":"42709","inReplyTo":"xmqqshvzddet.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] builtin/worktree.c: add option for setting worktree name","fromName":"Barret Rennie","fromEmail":"barret@brennie.ca","sentAt":"2016-06-27T05:40:15Z","receivedAt":"2016-06-27T05:40:29Z","isPatch":true,"sender":{"key":"barret@brennie.ca","avatar":"https://gravatar.com/avatar/9da1b9739ac5719000cbe46c5535ead1e58078d96da500f58b239a7edb4b2e00?d=mp&s=160"},"body":"\n> On Jun 26, 2016, at 12:15 PM, Junio C Hamano wrote:\n> \n> Junio C Hamano writes:\n> \n>> Now, if you do the worktree, you may still want the relative\n>> structure between these two, i.e. if you want to work on two\n>> different branch combinations of the whole thing, you would want to\n>> do this:\n>> \n>> $HOME/xyzzy-1/frotz - borrow from $HOME/xyzzy/frotz\n>> $HOME/xyzzy-1/libs/nitfol - likewise for nitfol\n>> \n>> $HOME/xyzzy-2/frotz - borrow from $HOME/xyzzy/frotz\n>> $HOME/xyzzy-2/libs/nitfol - likewise for nitfol\n>> \n>> where xyzzy-$n may be for topic-$n branch both in frotz and nitfol.\n>> \n>> And explained that way, it becomes clearer that you would want to\n>> name $HOME/xyzzy-1/frotz worktree after \"topic-1\", not the default\n>> name you would get \"frotz\" (because the default gives you the leaf\n>> level name of the newly created worktree).\n>> \n>> After the discussion above (which may or may not match what you\n>> raised this topic for), I think a feature to let you override the\n>> default name makes sense.\n>> \n>> It just needs to be explained better to help the users when the\n>> feature eventually becomes part of Git. Also, others (especially\n>> Duy) may have even better ideas (e.g. instead of having to always\n>> use --name to give custom name for all worktrees, set a \"hint\" just\n>> once to help the logic that comes up with the default name give a\n>> better name), so while the feature may be desirable, your exact\n>> implementation may or may not be what we eventually want to adopt.\n> \n> For example, the \"frotz\" and \"nitfol\" repositories (i.e. where their\n> worktrees borrow their refs and object stores from) could have a\n> single configuration variable each, i.e.\n> \n> \t(in $HOME/xyzzy/frotz/.git/config)\n> [worktree] location = \"~/*/frotz\"\n> \n> \t(in $HOME/xyzzy/libs/nitfol/.git/config)\n> [worktree] location = \"~/*/libs/nitfol\"\n> \n> and then the user could do in each of these two repositories\n> \n> \t$ git -C ~/xyzzy/frotz worktree add --by-name xyzzy-1 topic-1\n> \t$ git -C ~/xyzzy/lib/nitfol worktree add --by-name xyzzy-1 topic-1\n> \n> to get the desired layout instead.\n> \n> The traditional way may be \"create one HERE\", and your patch tries\n> to tweak it to \"create one at HERE with this NAME\". The above\n> attempts to remove the need for specifying the exact location every\n> time a new worktree is created, and instead let you specify the\n> systematic way in which you lay out your worktrees based on their\n> names.\n\nAre you proposing that `--by-name` creates a worktree in the current working\ndirectory or that the default behaviour of `git worktree add` is changed to\nto create the worktree in the current working directory when executed with\nonly one argument (the branch)?\n\nIn either case, I'm not sure what `worktree.location` does here, since we're\ncreating the worktree in the working directory, unless I'm misunderstanding\nyour example.\n"},{"id":"290221","messageId":"A2F194FC-281D-44DF-88CA-E0B8221A3E68@brennie.ca","threadId":"42709","inReplyTo":"CAPig+cRNUZZBw=F-Q2f3Ehc-8T2iBp4kvDusNRGv4ea5nihQVQ@mail.gmail.com","subject":"Re: [PATCH] builtin/worktree.c: add option for setting worktree name","fromName":"Barret Rennie","fromEmail":"barret@brennie.ca","sentAt":"2016-06-27T05:52:03Z","receivedAt":"2016-06-27T05:52:39Z","isPatch":true,"sender":{"key":"barret@brennie.ca","avatar":"https://gravatar.com/avatar/9da1b9739ac5719000cbe46c5535ead1e58078d96da500f58b239a7edb4b2e00?d=mp&s=160"},"body":"\n> On Jun 26, 2016, at 5:00 PM, Eric Sunshine wrote:\n> \n> On Sat, Jun 25, 2016 at 3:45 PM, Junio C Hamano wrote:\n>> [...snip...]\n>> And explained that way, it becomes clearer that you would want to\n>> name $HOME/xyzzy-1/frotz worktree after \"topic-1\", not the default\n>> name you would get \"frotz\" (because the default gives you the leaf\n>> level name of the newly created worktree).\n>> \n>> After the discussion above (which may or may not match what you\n>> raised this topic for), I think a feature to let you override the\n>> default name makes sense.\n> \n> One thing which hasn't been explained, and about which I'm still\n> confused even after reading this thread in its entirety, is what\n> Barret means when he says that he \"breaks\" his worktrees. What is the\n> nature of this breakage? Depending upon that answer, would \"git\n> rev-parse --git-dir\" be sufficient for your needs? Or, would \"git\n> worktree list\" be able to give you the desired information? (As\n> envisioned, \"git worktree list\" was intended to provide much more\n> information than it currently does, such as the .git/worktree dir\n> name, and such an enhancement might be welcome.)\n\nMy worktree breakages are usually the result of my reorganizing my projects,\nusually because a branch changes name (for example, if branch release-1 gets\npushed back to release-2). Then I go and rename all my directories and git \ngets unhappy and I have to manually fix them or re-create the worktrees.\n\nHaving `git worktree list` give the worktree directory would be very useful,\nbut I still would like the ability to change the name of a worktree.\n"},{"id":"290230","messageId":"xmqqk2hadb3z.fsf@gitster.mtv.corp.google.com","threadId":"42709","inReplyTo":"036C19B4-5941-43E4-AE2A-8782797D9523@brennie.ca","subject":"Re: [PATCH] builtin/worktree.c: add option for setting worktree name","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-06-27T13:17:52Z","receivedAt":"2016-06-27T13:18:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Barret Rennie writes:\n\n>> For example, the \"frotz\" and \"nitfol\" repositories (i.e. where their\n>> worktrees borrow their refs and object stores from) could have a\n>> single configuration variable each, i.e.\n>> \n>> \t(in $HOME/xyzzy/frotz/.git/config)\n>> [worktree] location = \"~/*/frotz\"\n>> \n>> \t(in $HOME/xyzzy/libs/nitfol/.git/config)\n>> [worktree] location = \"~/*/libs/nitfol\"\n>> \n>> and then the user could do in each of these two repositories\n>> \n>> \t$ git -C ~/xyzzy/frotz worktree add --by-name xyzzy-1 topic-1\n>> \t$ git -C ~/xyzzy/lib/nitfol worktree add --by-name xyzzy-1 topic-1\n>> \n>> to get the desired layout instead.\n>> \n>> The traditional way may be \"create one HERE\", and your patch tries\n>> to tweak it to \"create one at HERE with this NAME\". The above\n>> attempts to remove the need for specifying the exact location every\n>> time a new worktree is created, and instead let you specify the\n>> systematic way in which you lay out your worktrees based on their\n>> names.\n>\n> Are you proposing that `--by-name` creates a worktree in the current working\n> directory or that the default behaviour of `git worktree add` is changed to\n> to create the worktree in the current working directory when executed with\n> only one argument (the branch)?\n\nIt is not a proposal but an illustration of what I meant by \"hint\".\n\nWhat I am envisioning is that we may enhance the \"worktree add\"\nsubcommand to take two forms. In addition to traditional\n\n $ git worktree add [opts] []\n\nwhen worktree.location configuration is present, you could say\n\n $ git worktree add [opts] --by-name []\n\nomitting and instead giving . Use the to\nsubstitute the wildcard in the pattern given by worktree.location,\ni.e. with the above example for \"frotz\",\n\n $ git worktree add --by-name xyzzy-1 topic-1\n\nbecause the worktree.location configuration is set to \"~/*/frotz\",\nthat would act as if was given as ~/xyzzy-1/frotz. Name is\nset to xyzzy-1, and the newly created worktree would initially check\nout topic-1 branch.\n"},{"id":"290331","messageId":"CAPig+cSEwib1iFyWE5h8-qTbsAC+zsaSDSYQnv6otWoOOjWAeA@mail.gmail.com","threadId":"42709","inReplyTo":"A2F194FC-281D-44DF-88CA-E0B8221A3E68@brennie.ca","subject":"Re: [PATCH] builtin/worktree.c: add option for setting worktree name","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2016-06-27T23:11:34Z","receivedAt":"2016-06-27T23:11:41Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Mon, Jun 27, 2016 at 1:52 AM, Barret Rennie wrote:\n> On Jun 26, 2016, at 5:00 PM, Eric Sunshine wrote:\n>> One thing which hasn't been explained, and about which I'm still\n>> confused even after reading this thread in its entirety, is what\n>> Barret means when he says that he \"breaks\" his worktrees. What is the\n>> nature of this breakage? Depending upon that answer, would \"git\n>> rev-parse --git-dir\" be sufficient for your needs? Or, would \"git\n>> worktree list\" be able to give you the desired information? (As\n>> envisioned, \"git worktree list\" was intended to provide much more\n>> information than it currently does, such as the .git/worktree dir\n>> name, and such an enhancement might be welcome.)\n>\n> My worktree breakages are usually the result of my reorganizing my projects,\n> usually because a branch changes name (for example, if branch release-1 gets\n> pushed back to release-2). Then I go and rename all my directories and git\n> gets unhappy and I have to manually fix them or re-create the worktrees.\n\nQuoting from your earlier email justifying why you consider this patch\ndesirable:\n\n ...when I break my worktrees and can’t figure out\n which worktree dir is the one I’ve broken.\n\nBut, doesn't \"git rev-parse --git-dir\" from within a \"broken\" worktree\nanswer that question? Or, wouldn't an enhanced \"git worktree list\"\nanswer the question from the opposite side?\n\n> Having `git worktree list` give the worktree directory would be very useful,\n> but I still would like the ability to change the name of a worktree.\n\nMy knee-jerk reaction is that the directory name under .git/worktrees\nis an implementation detail (and could easily have been an arbitrary\nID, such as .git/worktrees/7ba84ec0) and rather than exposing it\nfurther and encouraging people to muck around in it manually, we\nshould be providing higher-level solutions so that they don't have to.\n\nEven without the higher-level solutions, it seems like \"git rev-parse\n--git-dir\" should satisfy your needs, and if someone enhances \"git\nworktree list\" to provide the additional worktree tag name (as\nenvisioned all along), then you'd likewise have sufficient information\nto \"fix\" your worktrees.\n\nAs an example of higher-level solutions, Duy's \"git worktree move\"\nseries[1] would, I think, be exactly what you need to avoid such\nbreakage in the first place (assuming you can retrain your fingers or\nfix your scripts, if they are doing the worktree renaming).\n\nI don't know how Duy and Junio feel about it, but my response to this\npatch and what it wants to accomplish (even with Junio's input) is\nfairly negative. I'd much rather see more missing high-level worktree\nfeatures implemented rather than see patches further exposing\ngit-worktree's internals.\n\n[1]: http://thread.gmane.org/gmane.comp.version-control.git/298194\n"},{"id":"290454","messageId":"89E234AF-9498-4425-812B-BB0DED4216DA@brennie.ca","threadId":"42709","inReplyTo":"CAPig+cSEwib1iFyWE5h8-qTbsAC+zsaSDSYQnv6otWoOOjWAeA@mail.gmail.com","subject":"Re: [PATCH] builtin/worktree.c: add option for setting worktree name","fromName":"Barret Rennie","fromEmail":"barret@brennie.ca","sentAt":"2016-06-29T04:45:05Z","receivedAt":"2016-06-29T04:45:25Z","isPatch":true,"sender":{"key":"barret@brennie.ca","avatar":"https://gravatar.com/avatar/9da1b9739ac5719000cbe46c5535ead1e58078d96da500f58b239a7edb4b2e00?d=mp&s=160"},"body":"\n> On Jun 27, 2016, at 5:11 PM, Eric Sunshine wrote:\n> \n> [snip]\n> \n> My knee-jerk reaction is that the directory name under .git/worktrees\n> is an implementation detail (and could easily have been an arbitrary\n> ID, such as .git/worktrees/7ba84ec0) and rather than exposing it\n> further and encouraging people to muck around in it manually, we\n> should be providing higher-level solutions so that they don't have to.\n> \n> Even without the higher-level solutions, it seems like \"git rev-parse\n> --git-dir\" should satisfy your needs, and if someone enhances \"git\n> worktree list\" to provide the additional worktree tag name (as\n> envisioned all along), then you'd likewise have sufficient information\n> to \"fix\" your worktrees.\n> \n> As an example of higher-level solutions, Duy's \"git worktree move\"\n> series[1] would, I think, be exactly what you need to avoid such\n> breakage in the first place (assuming you can retrain your fingers or\n> fix your scripts, if they are doing the worktree renaming).\n> \n> I don't know how Duy and Junio feel about it, but my response to this\n> patch and what it wants to accomplish (even with Junio's input) is\n> fairly negative. I'd much rather see more missing high-level worktree\n> features implemented rather than see patches further exposing\n> git-worktree's internals.\n> \n> [1]: http://thread.gmane.org/gmane.comp.version-control.git/298194\nYes, it does seem like `git worktree move` will solve all my issues and\nis a much more elegant solution. Thanks for pointing it out to me and\nlooking at this patch.\n\nI may write a patch to print out the worktree tag name instead and submit\nthat later.\n\nRegards,\nBarret Rennie\n"}]}