{"thread":{"id":"45663","subject":"git work trees","startedAt":"2017-04-11T15:25:18Z","lastAt":"2017-04-24T14:18:41Z","messageCount":10,"participants":["taylor, david","Duy Nguyen","Nguyễn Thái Ngọc Duy","Junio C Hamano","Jacob Keller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"316599","messageId":"63F1AEE13FAE864586D589C671A6E18B0CFBF7@MX203CL03.corp.emc.com","threadId":"45663","inReplyTo":null,"subject":"git work trees","fromName":"taylor, david","fromEmail":"david.taylor@dell.com","sentAt":"2017-04-11T15:14:57Z","receivedAt":"2017-04-11T15:25:18Z","isPatch":false,"sender":{"key":"david.taylor@dell.com","avatar":null},"body":"We are using Git in a distributed environment.\n\nIn the United States, we have the master repository in one state and a build cluster in a different state.\nIn addition to people in the US doing builds, we have people in other countries (Ireland, India, Israel,\nRussia, possibly others) doing builds -- using the build cluster.\n\nThe local mirror of the repository is NFS accessible. The plan is to make builds faster through the use\nof work trees. The build cluster nodes involved in the build will have a worktree in RAM -- checked out\nfor the duration of the build. Since the worktree is in RAM, it will not be NFS accessible.\n\n[Cloning takes 20+ minutes when the network is unloaded. Building, with sources NFS mounted, takes\n5-10 minutes.]\n\nThis presents a few problems.\n\nWhen we are done with a work tree, we want to clean up -- think: prune. But, you cannot prune just\none worktree; you have to prune the set. And no machine has access to all the worktrees. So, no\nmachine knows which ones are prunable.\n\nThere is no 'lock' option to 'add'. If someone does a 'prune' after you do an 'add' and before you do a\n'lock', then your 'add' is undone.\n\nAre there any plans to add a '[--lock]' option to 'add' to create the worktree in the locked state? And/or\nplans to add a [...] option to prune to say 'prune only this path / these paths'?\n\nIf there are no plans, is the above an acceptable interface? And if we implemented it, would it be looked\nupon favorably?\n\nThanks.\n"},{"id":"316688","messageId":"CACsJy8CBjO+Wg187LUTGs1nna1trV2nukgS9uK74PcY-dEFGaA@mail.gmail.com","threadId":"45663","inReplyTo":"63F1AEE13FAE864586D589C671A6E18B0CFBF7@MX203CL03.corp.emc.com","subject":"Re: git work trees","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2017-04-12T13:36:03Z","receivedAt":"2017-04-12T13:36:44Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Apr 11, 2017 at 10:14 PM, taylor, david wrote:\n> We are using Git in a distributed environment.\n>\n> In the United States, we have the master repository in one state and a build cluster in a different state.\n> In addition to people in the US doing builds, we have people in other countries (Ireland, India, Israel,\n> Russia, possibly others) doing builds -- using the build cluster.\n>\n> The local mirror of the repository is NFS accessible. The plan is to make builds faster through the use\n> of work trees. The build cluster nodes involved in the build will have a worktree in RAM -- checked out\n> for the duration of the build. Since the worktree is in RAM, it will not be NFS accessible.\n>\n> [Cloning takes 20+ minutes when the network is unloaded. Building, with sources NFS mounted, takes\n> 5-10 minutes.]\n\nUsing worktrees in this scenario kinda defeats the distributed nature\nof git. Cloning takes long, yes. But what about just \"git pull\" (or\n\"git fetch && git checkout -f\" if you want to avoid merging)?\n\n> This presents a few problems.\n>\n> When we are done with a work tree, we want to clean up -- think: prune. But, you cannot prune just\n> one worktree; you have to prune the set. And no machine has access to all the worktrees. So, no\n> machine knows which ones are prunable.\n\nBy \"prune one worktree\", did you mean delete one? Or delete a branch\nthe worktree uses and prune the object database?\n\n> There is no 'lock' option to 'add'. If someone does a 'prune' after you do an 'add' and before you do a\n> 'lock', then your 'add' is undone.\n>\n> Are there any plans to add a '[--lock]' option to 'add' to create the worktree in the locked state? And/or\n> plans to add a [...] option to prune to say 'prune only this path / these paths'?\n\nSo this is \"git worktree prune\". Adding \"worktree add --locked\" sounds\nreasonable (and quite simple too, because \"worktree add\" does lock the\nworktree at creation time; we just need to stop it from releasing the\nlock). I might be able to do it quickly (it does not mean \"available\nin the next release\" though).\n\nIf you need to just prune \"this path\", I think it's the equivalent of\n\"git worktree remove\" (i.e. delete a specific worktree). Work has been\ngoing on for a while to add that command. Maybe it'll be available\nlater this year.\n\n> If there are no plans, is the above an acceptable interface? And if we implemented it, would it be looked\n> upon favorably?\n\nSpeaking of this use case (and this is my own opinion) I think this is\nstretching \"git worktree\" too much. When I created it, I imagined this\nfunctionality to be used by a single person.\n-- \nDuy\n"},{"id":"316689","messageId":"20170412135805.29837-1-pclouds@gmail.com","threadId":"45663","inReplyTo":"63F1AEE13FAE864586D589C671A6E18B0CFBF7@MX203CL03.corp.emc.com","subject":"[PATCH] worktree add: add --lock option","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2017-04-12T13:58:05Z","receivedAt":"2017-04-12T13:58:29Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"As explained in the document. This option has an advantage over the\ncommand sequence \"git worktree add && git worktree lock\": there will be\nno gap that somebody can accidentally \"prune\" the new worktree (or soon,\nexplicitly \"worktree remove\" it).\n\n\"worktree add\" does keep a lock on while it's preparing the worktree.\nIf --lock is specified, this lock remains after the worktree is created.\n\nSuggested-by: David Taylor \nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n A patch that adds --lock may look like this.\n\n Documentation/git-worktree.txt | 7 ++++++-\n builtin/worktree.c | 12 +++++++++++-\n t/t2025-worktree-add.sh | 6 ++++++\n 3 files changed, 23 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt\nindex 553cf8413f..b472acc356 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] [--lock] [-b ] []\n 'git worktree list' [--porcelain]\n 'git worktree lock' [--reason ] \n 'git worktree prune' [-n] [-v] [--expire ]\n@@ -107,6 +107,11 @@ OPTIONS\n \tsuch as configuring sparse-checkout. See \"Sparse checkout\"\n \tin linkgit:git-read-tree[1].\n \n+--lock::\n+\tKeep the working tree locked after creation. This is the\n+\tequivalent of `git worktree lock` after `git worktree add`,\n+\tbut without race condition.\n+\n -n::\n --dry-run::\n \tWith `prune`, do not remove anything; just report what it would\ndiff --git a/builtin/worktree.c b/builtin/worktree.c\nindex 9993ded41a..3dab07c829 100644\n--- a/builtin/worktree.c\n+++ b/builtin/worktree.c\n@@ -24,6 +24,7 @@ struct add_opts {\n \tint force;\n \tint detach;\n \tint checkout;\n+\tint keep_locked;\n \tconst char *new_branch;\n \tint force_new_branch;\n };\n@@ -305,7 +306,15 @@ static int add_worktree(const char *path, const char *refname,\n done:\n \tstrbuf_reset(&sb);\n \tstrbuf_addf(&sb, \"%s/locked\", sb_repo.buf);\n-\tunlink_or_warn(sb.buf);\n+\tif (!ret && opts->keep_locked) {\n+\t\t/*\n+\t\t * Don't keep the confusing \"initializing\" message\n+\t\t * after it's already over.\n+\t\t */\n+\t\ttruncate(sb.buf, 0);\n+\t} else {\n+\t\tunlink_or_warn(sb.buf);\n+\t}\n \targv_array_clear(&child_env);\n \tstrbuf_release(&sb);\n \tstrbuf_release(&symref);\n@@ -328,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_BOOL(0, \"lock\", &opts.keep_locked, N_(\"keep the new working tree locked\")),\n \t\tOPT_END()\n \t};\n \ndiff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh\nindex b618d6be21..6dce920c03 100755\n--- a/t/t2025-worktree-add.sh\n+++ b/t/t2025-worktree-add.sh\n@@ -63,6 +63,12 @@ test_expect_success '\"add\" worktree' '\n \t)\n '\n \n+test_expect_success '\"add\" worktree with lock' '\n+\tgit rev-parse HEAD >expect &&\n+\tgit worktree add --detach --lock here-with-lock master &&\n+\ttest_must_be_empty .git/worktrees/here-with-lock/locked\n+'\n+\n test_expect_success '\"add\" worktree from a subdir' '\n \t(\n \t\tmkdir sub &&\n-- \n2.11.0.157.gd943d85\n\n"},{"id":"316798","messageId":"xmqqy3v3orc3.fsf@gitster.mtv.corp.google.com","threadId":"45663","inReplyTo":"20170412135805.29837-1-pclouds@gmail.com","subject":"Re: [PATCH] worktree add: add --lock option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-04-13T22:50:04Z","receivedAt":"2017-04-13T22:50:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyễn Thái Ngọc Duy writes:\n\n> As explained in the document. This option has an advantage over the\n> command sequence \"git worktree add && git worktree lock\": there will be\n> no gap that somebody can accidentally \"prune\" the new worktree (or soon,\n> explicitly \"worktree remove\" it).\n>\n> \"worktree add\" does keep a lock on while it's preparing the worktree.\n> If --lock is specified, this lock remains after the worktree is created.\n>\n> Suggested-by: David Taylor \n> Signed-off-by: Nguyễn Thái Ngọc Duy \n> ---\n> A patch that adds --lock may look like this.\n\nThis looks more like \"I do believe the idea by David is a useful\naddition and here is how I did it to the best of my ability---let's\nmake sure we polish it for eventual inclusion\" than a mere \"it may\nlook like so---do whatever you want with it\" patch.\n\nTo me \"git worktree add --lock\" somehow sounds less correct than\n\"git worktree add --locked\", but I'd appreciate if natives can\ncorrect me.\n\nThanks.\n"},{"id":"316813","messageId":"CACsJy8D_S+KNTxLp7QT5KzvCmdjuQZ++saYAaikkO7beRDwzJQ@mail.gmail.com","threadId":"45663","inReplyTo":"xmqqy3v3orc3.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] worktree add: add --lock option","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2017-04-14T13:00:51Z","receivedAt":"2017-04-14T13:01:27Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, Apr 14, 2017 at 5:50 AM, Junio C Hamano wrote:\n> Nguyễn Thái Ngọc Duy writes:\n>\n>> As explained in the document. This option has an advantage over the\n>> command sequence \"git worktree add && git worktree lock\": there will be\n>> no gap that somebody can accidentally \"prune\" the new worktree (or soon,\n>> explicitly \"worktree remove\" it).\n>>\n>> \"worktree add\" does keep a lock on while it's preparing the worktree.\n>> If --lock is specified, this lock remains after the worktree is created.\n>>\n>> Suggested-by: David Taylor \n>> Signed-off-by: Nguyễn Thái Ngọc Duy \n>> ---\n>> A patch that adds --lock may look like this.\n>\n> This looks more like \"I do believe the idea by David is a useful\n> addition and here is how I did it to the best of my ability---let's\n> make sure we polish it for eventual inclusion\" than a mere \"it may\n> look like so---do whatever you want with it\" patch.\n\nIt is a good addition, which is why I added tests and documents, so it\nmay have a chance for inclusion. I would not strongly defend it though\nif there's objection.\n\n> To me \"git worktree add --lock\" somehow sounds less correct than\n> \"git worktree add --locked\", but I'd appreciate if natives can\n> correct me.\n\nThat was my first choice too. Then I saw --detach (instead of\n--detached). I didn't care much and went with a verb like the rest.\n-- \nDuy\n"},{"id":"316816","messageId":"CA+P7+xrdM-DGbs4PcN-E+yh=A5Fr40ZGr2RaoihkooUnorfHxA@mail.gmail.com","threadId":"45663","inReplyTo":"xmqqy3v3orc3.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] worktree add: add --lock option","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2017-04-14T16:27:06Z","receivedAt":"2017-04-14T16:27:33Z","isPatch":true,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Thu, Apr 13, 2017 at 3:50 PM, Junio C Hamano wrote:\n> Nguyễn Thái Ngọc Duy writes:\n>\n>> As explained in the document. This option has an advantage over the\n>> command sequence \"git worktree add && git worktree lock\": there will be\n>> no gap that somebody can accidentally \"prune\" the new worktree (or soon,\n>> explicitly \"worktree remove\" it).\n>>\n>> \"worktree add\" does keep a lock on while it's preparing the worktree.\n>> If --lock is specified, this lock remains after the worktree is created.\n>>\n>> Suggested-by: David Taylor \n>> Signed-off-by: Nguyễn Thái Ngọc Duy \n>> ---\n>> A patch that adds --lock may look like this.\n>\n> This looks more like \"I do believe the idea by David is a useful\n> addition and here is how I did it to the best of my ability---let's\n> make sure we polish it for eventual inclusion\" than a mere \"it may\n> look like so---do whatever you want with it\" patch.\n>\n> To me \"git worktree add --lock\" somehow sounds less correct than\n> \"git worktree add --locked\", but I'd appreciate if natives can\n> correct me.\n>\n> Thanks.\n\nI think either \"--lock\" or \"--locked\" works for me. \"--locked'\nsuggests \"this is the state I want the tree in\" while \"--lock\"\nsuggests \"this is the action I want taken on the tree\".\n\nThanks,\nJake\n"},{"id":"316871","messageId":"xmqqzifim8co.fsf@gitster.mtv.corp.google.com","threadId":"45663","inReplyTo":"20170412135805.29837-1-pclouds@gmail.com","subject":"Re: [PATCH] worktree add: add --lock option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-04-15T07:35:19Z","receivedAt":"2017-04-15T07:35:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyễn Thái Ngọc Duy writes:\n\n> -\tunlink_or_warn(sb.buf);\n> +\tif (!ret && opts->keep_locked) {\n> +\t\t/*\n> +\t\t * Don't keep the confusing \"initializing\" message\n> +\t\t * after it's already over.\n> +\t\t */\n> +\t\ttruncate(sb.buf, 0);\n> +\t} else {\n> +\t\tunlink_or_warn(sb.buf);\n> +\t}\n\nbuiltin/worktree.c: In function 'add_worktree':\nbuiltin/worktree.c:314:11: error: ignoring return value of 'truncate', declared with attribute warn_unused_result [-Werror=unused-result]\n truncate(sb.buf, 0);\n ^\ncc1: all warnings being treated as errors\nmake: *** [builtin/worktree.o] Error 1\n"},{"id":"316873","messageId":"xmqqmvbim6vi.fsf@gitster.mtv.corp.google.com","threadId":"45663","inReplyTo":"xmqqzifim8co.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] worktree add: add --lock option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-04-15T08:07:13Z","receivedAt":"2017-04-15T08:07:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Nguyễn Thái Ngọc Duy writes:\n>\n>> -\tunlink_or_warn(sb.buf);\n>> +\tif (!ret && opts->keep_locked) {\n>> +\t\t/*\n>> +\t\t * Don't keep the confusing \"initializing\" message\n>> +\t\t * after it's already over.\n>> +\t\t */\n>> +\t\ttruncate(sb.buf, 0);\n>> +\t} else {\n>> +\t\tunlink_or_warn(sb.buf);\n>> +\t}\n>\n> builtin/worktree.c: In function 'add_worktree':\n> builtin/worktree.c:314:11: error: ignoring return value of 'truncate', declared with attribute warn_unused_result [-Werror=unused-result]\n> truncate(sb.buf, 0);\n> ^\n> cc1: all warnings being treated as errors\n> make: *** [builtin/worktree.o] Error 1\n\nI wonder why we need to have \"initializing\" and then remove the\nstring. Wouldn't it be simpler to do something like this instead?\nDoes an empty lockfile have some special meaning?\n\n builtin/worktree.c | 16 +++++++---------\n t/t2025-worktree-add.sh | 3 +--\n 2 files changed, 8 insertions(+), 11 deletions(-)\n\ndiff --git a/builtin/worktree.c b/builtin/worktree.c\nindex 3dab07c829..5ebdcce793 100644\n--- a/builtin/worktree.c\n+++ b/builtin/worktree.c\n@@ -243,7 +243,10 @@ static int add_worktree(const char *path, const char *refname,\n \t * after the preparation is over.\n \t */\n \tstrbuf_addf(&sb, \"%s/locked\", sb_repo.buf);\n-\twrite_file(sb.buf, \"initializing\");\n+\tif (!opts->keep_locked)\n+\t\twrite_file(sb.buf, \"initializing\");\n+\telse\n+\t\twrite_file(sb.buf, \"added with --lock\");\n \n \tstrbuf_addf(&sb_git, \"%s/.git\", path);\n \tif (safe_create_leading_directories_const(sb_git.buf))\n@@ -306,15 +309,10 @@ static int add_worktree(const char *path, const char *refname,\n done:\n \tstrbuf_reset(&sb);\n \tstrbuf_addf(&sb, \"%s/locked\", sb_repo.buf);\n-\tif (!ret && opts->keep_locked) {\n-\t\t/*\n-\t\t * Don't keep the confusing \"initializing\" message\n-\t\t * after it's already over.\n-\t\t */\n-\t\ttruncate(sb.buf, 0);\n-\t} else {\n+\tif (!ret && opts->keep_locked)\n+\t\t;\n+\telse\n \t\tunlink_or_warn(sb.buf);\n-\t}\n \targv_array_clear(&child_env);\n \tstrbuf_release(&sb);\n \tstrbuf_release(&symref);\ndiff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh\nindex 6dce920c03..304f25fcd1 100755\n--- a/t/t2025-worktree-add.sh\n+++ b/t/t2025-worktree-add.sh\n@@ -65,8 +65,7 @@ test_expect_success '\"add\" worktree' '\n \n test_expect_success '\"add\" worktree with lock' '\n \tgit rev-parse HEAD >expect &&\n-\tgit worktree add --detach --lock here-with-lock master &&\n-\ttest_must_be_empty .git/worktrees/here-with-lock/locked\n+\tgit worktree add --detach --lock here-with-lock master\n '\n \n test_expect_success '\"add\" worktree from a subdir' '\n"},{"id":"316885","messageId":"CACsJy8A=Pi8uaEumhddzySEywxAS8vau5mv-sEewmuwNUvZp_A@mail.gmail.com","threadId":"45663","inReplyTo":"xmqqmvbim6vi.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] worktree add: add --lock option","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2017-04-15T11:34:27Z","receivedAt":"2017-04-15T11:35:03Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sat, Apr 15, 2017 at 3:07 PM, Junio C Hamano wrote:\n> Junio C Hamano writes:\n>\n>> Nguyễn Thái Ngọc Duy writes:\n>>\n>>> - unlink_or_warn(sb.buf);\n>>> + if (!ret && opts->keep_locked) {\n>>> + /*\n>>> + * Don't keep the confusing \"initializing\" message\n>>> + * after it's already over.\n>>> + */\n>>> + truncate(sb.buf, 0);\n>>> + } else {\n>>> + unlink_or_warn(sb.buf);\n>>> + }\n>>\n>> builtin/worktree.c: In function 'add_worktree':\n>> builtin/worktree.c:314:11: error: ignoring return value of 'truncate', declared with attribute warn_unused_result [-Werror=unused-result]\n>> truncate(sb.buf, 0);\n>> ^\n\nYes it's supposed to be safe to ignore the error in this case. I\nthought of adding (void) last minute but didn't do it.\n\n\n>> cc1: all warnings being treated as errors\n>> make: *** [builtin/worktree.o] Error 1\n>\n> I wonder why we need to have \"initializing\" and then remove the\n> string. Wouldn't it be simpler to do something like this instead?\n> Does an empty lockfile have some special meaning?\n\nIt's mostly for troubleshooting. If \"git worktree add\" fails in a\nlater phase with a valid/locked worktree remains, this gives us a\nclue.\n\n> builtin/worktree.c | 16 +++++++---------\n> t/t2025-worktree-add.sh | 3 +--\n> 2 files changed, 8 insertions(+), 11 deletions(-)\n>\n> diff --git a/builtin/worktree.c b/builtin/worktree.c\n> index 3dab07c829..5ebdcce793 100644\n> --- a/builtin/worktree.c\n> +++ b/builtin/worktree.c\n> @@ -243,7 +243,10 @@ static int add_worktree(const char *path, const char *refname,\n> * after the preparation is over.\n> */\n> strbuf_addf(&sb, \"%s/locked\", sb_repo.buf);\n> - write_file(sb.buf, \"initializing\");\n> + if (!opts->keep_locked)\n> + write_file(sb.buf, \"initializing\");\n> + else\n> + write_file(sb.buf, \"added with --lock\");\n>\n> strbuf_addf(&sb_git, \"%s/.git\", path);\n> if (safe_create_leading_directories_const(sb_git.buf))\n> @@ -306,15 +309,10 @@ static int add_worktree(const char *path, const char *refname,\n> done:\n> strbuf_reset(&sb);\n> strbuf_addf(&sb, \"%s/locked\", sb_repo.buf);\n> - if (!ret && opts->keep_locked) {\n> - /*\n> - * Don't keep the confusing \"initializing\" message\n> - * after it's already over.\n> - */\n> - truncate(sb.buf, 0);\n> - } else {\n> + if (!ret && opts->keep_locked)\n> + ;\n> + else\n> unlink_or_warn(sb.buf);\n> - }\n> argv_array_clear(&child_env);\n> strbuf_release(&sb);\n> strbuf_release(&symref);\n> diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh\n> index 6dce920c03..304f25fcd1 100755\n> --- a/t/t2025-worktree-add.sh\n> +++ b/t/t2025-worktree-add.sh\n> @@ -65,8 +65,7 @@ test_expect_success '\"add\" worktree' '\n>\n> test_expect_success '\"add\" worktree with lock' '\n> git rev-parse HEAD >expect &&\n> - git worktree add --detach --lock here-with-lock master &&\n> - test_must_be_empty .git/worktrees/here-with-lock/locked\n> + git worktree add --detach --lock here-with-lock master\n\nI think you still need to check for the presence of \"locked\" file.\n\n> '\n>\n> test_expect_success '\"add\" worktree from a subdir' '\n-- \nDuy\n"},{"id":"317692","messageId":"63F1AEE13FAE864586D589C671A6E18B0D23F9@MX203CL03.corp.emc.com","threadId":"45663","inReplyTo":"CACsJy8D_S+KNTxLp7QT5KzvCmdjuQZ++saYAaikkO7beRDwzJQ@mail.gmail.com","subject":"RE: [PATCH] worktree add: add --lock option","fromName":"taylor, david","fromEmail":"david.taylor@dell.com","sentAt":"2017-04-24T14:06:59Z","receivedAt":"2017-04-24T14:18:41Z","isPatch":true,"sender":{"key":"david.taylor@dell.com","avatar":null},"body":"\n> From: Duy Nguyen [mailto:pclouds@gmail.com]\n> Sent: Friday, April 14, 2017 9:01 AM\n> To: Junio C Hamano\n> Cc: Git Mailing List; taylor, david\n> Subject: Re: [PATCH] worktree add: add --lock option\n> \n> On Fri, Apr 14, 2017 at 5:50 AM, Junio C Hamano \n> wrote:\n> > Nguyễn Thái Ngọc Duy writes:\n> >\n> >> As explained in the document. This option has an advantage over the\n> >> command sequence \"git worktree add && git worktree lock\": there will be\n> >> no gap that somebody can accidentally \"prune\" the new worktree (or\n> soon,\n> >> explicitly \"worktree remove\" it).\n> >>\n> >> \"worktree add\" does keep a lock on while it's preparing the worktree.\n> >> If --lock is specified, this lock remains after the worktree is created.\n> >>\n> >> Suggested-by: David Taylor \n> >> Signed-off-by: Nguyễn Thái Ngọc Duy \n> >> ---\n> >> A patch that adds --lock may look like this.\n> >\n> > This looks more like \"I do believe the idea by David is a useful\n> > addition and here is how I did it to the best of my ability---let's\n> > make sure we polish it for eventual inclusion\" than a mere \"it may\n> > look like so---do whatever you want with it\" patch.\n> \n> It is a good addition, which is why I added tests and documents, so it\n> may have a chance for inclusion. I would not strongly defend it though\n> if there's objection.\n> \n> > To me \"git worktree add --lock\" somehow sounds less correct than\n> > \"git worktree add --locked\", but I'd appreciate if natives can\n> > correct me.\n> \n> That was my first choice too. Then I saw --detach (instead of\n> --detached). I didn't care much and went with a verb like the rest.\n\nWhile I personally would prefer --locked, I also prefer keeping it 'parallel\nconstruction' with --detach. That is either [--detach][--lock] or\n[--detached][--locked]. But, ultimately, my intended use is within a script,\nso even if it was --totally-non-mnemonic-option I would cope.\n\nA stronger desire, regardless of whether it's Duy's implementation, mine, or\nsomeone elses, is to have something acceptable to the community so that\nwe are not maintaining a fork with the attendant need to merge changes\nin each time we upgrade.\n\n> --\n> Duy\n"}]}