{"thread":{"id":"41661","subject":"[PATCH 0/1] Introduce a way to create a branch and worktree at the same time","startedAt":"2016-03-10T11:34:10Z","lastAt":"2016-03-15T20:40:23Z","messageCount":16,"participants":["Johannes Schindelin","Duy Nguyen","Eric Sunshine","Mikael Magnusson","Junio C Hamano","Johannes Sixt"],"isPatch":true,"patchVersion":1,"patchTotal":1},"messages":[{"id":"280547","messageId":"cover.1457609615.git.johannes.schindelin@gmx.de","threadId":"41661","inReplyTo":null,"subject":"[PATCH 0/1] Introduce a way to create a branch and worktree at the same time","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-03-10T11:34:10Z","receivedAt":"2016-03-10T11:34:10Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"The invention of the `git worktree` command changed this developer's\nworking style dramatically. Rather than switching between branches all\nthe time, topic branches are created and checked out in newly-added\nworktrees, to be reworked and refined until the topic branch is either\nmerged into `master` or abandoned.\n\nIt gets rather tiresome, and also typo-prone, to call \"git branch xyz\nupstream/master && git worktree add xyz xyz\" all the time. Hence this\nproposal: \"git branch -w xyz upstream/master\" to do the same.\n\nThe plan is to also support \"git branch -d -w xyz\" once the `git\nworktree` command learned a `remove` (or `delete`) subcommand.\n\nOne possible improvement would be to add \"/xyz/\" to the parent\nrepository's .git/info/exclude, but this developer hesitates to\nintroduce that feature without the \"delete\" counterpart: those exclude\nentries would likely go stale very quickly. Besides, there might be a\nplan in the working to exclude worktrees automagically?\n\n\nJohannes Schindelin (1):\n  branch: allow conveniently adding new worktrees for new branches\n\n Documentation/git-branch.txt |  5 +++--\n builtin/branch.c             | 27 +++++++++++++++++++++++++--\n 2 files changed, 28 insertions(+), 4 deletions(-)\n\n-- \n2.7.2.windows.1.8.g47d64e6.dirty\n"},{"id":"280548","messageId":"c5345f60e4ec247d57877e3e97a1eea5cb283d27.1457609615.git.johannes.schindelin@gmx.de","threadId":"41661","inReplyTo":"cover.1457609615.git.johannes.schindelin@gmx.de","subject":"[PATCH 1/1] branch: allow conveniently adding new worktrees for new branches","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-03-10T11:34:28Z","receivedAt":"2016-03-10T11:34:28Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"With the newly-introduced --worktree option, after a new branch was\ncreated we will add a corresponding new worktree with the same name\nautomatically.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n Documentation/git-branch.txt |  5 +++--\n builtin/branch.c             | 27 +++++++++++++++++++++++++--\n 2 files changed, 28 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt\nindex 4a7037f..963cdcb 100644\n--- a/Documentation/git-branch.txt\n+++ b/Documentation/git-branch.txt\n@@ -13,7 +13,7 @@ SYNOPSIS\n \t[--column[=<options>] | --no-column]\n \t[(--merged | --no-merged | --contains) [<commit>]] [--sort=<key>]\n \t[--points-at <object>] [<pattern>...]\n-'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>]\n+'git branch' [--set-upstream | --track | --no-track] [-l] [-f] [-w | --worktree] <branchname> [<start-point>]\n 'git branch' (--set-upstream-to=<upstream> | -u <upstream>) [<branchname>]\n 'git branch' --unset-upstream [<branchname>]\n 'git branch' (-m | -M) [<oldbranch>] <newbranch>\n@@ -46,7 +46,8 @@ which points to the current 'HEAD', or <start-point> if given.\n \n Note that this will create the new branch, but it will not switch the\n working tree to it; use \"git checkout <newbranch>\" to switch to the\n-new branch.\n+new branch, or use the `--worktree` option to add a new worktree of\n+the same name.\n \n When a local branch is started off a remote-tracking branch, Git sets up the\n branch (specifically the `branch.<name>.remote` and `branch.<name>.merge`\ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex 7b45b6b..c681b2e 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -20,6 +20,7 @@\n #include \"utf8.h\"\n #include \"wt-status.h\"\n #include \"ref-filter.h\"\n+#include \"run-command.h\"\n \n static const char * const builtin_branch_usage[] = {\n \tN_(\"git branch [<options>] [-r | -a] [--merged | --no-merged]\"),\n@@ -605,7 +606,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n {\n \tint delete = 0, rename = 0, force = 0, list = 0;\n \tint reflog = 0, edit_description = 0;\n-\tint quiet = 0, unset_upstream = 0;\n+\tint quiet = 0, unset_upstream = 0, new_worktree = 0;\n \tconst char *new_upstream = NULL;\n \tenum branch_track track;\n \tstruct ref_filter filter;\n@@ -622,6 +623,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\t\tBRANCH_TRACK_OVERRIDE),\n \t\tOPT_STRING('u', \"set-upstream-to\", &new_upstream, \"upstream\", \"change the upstream info\"),\n \t\tOPT_BOOL(0, \"unset-upstream\", &unset_upstream, \"Unset the upstream info\"),\n+\t\tOPT_BIT('w', \"worktree\", &new_worktree, N_(\"add worktree for the new branch\"), 1),\n \t\tOPT__COLOR(&branch_use_color, N_(\"use colored output\")),\n \t\tOPT_SET_INT('r', \"remotes\",     &filter.kind, N_(\"act on remote-tracking branches\"),\n \t\t\tFILTER_REFS_REMOTES),\n@@ -678,6 +680,13 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \tif (!delete && !rename && !edit_description && !new_upstream && !unset_upstream && argc == 0)\n \t\tlist = 1;\n \n+\tif (new_worktree) {\n+\t\tif (delete || rename || new_upstream || unset_upstream)\n+\t\t\tdie(\"--worktree requires creating a new branch\");\n+\t\tif (new_worktree && (argc < 1 || argc > 2))\n+\t\t\tdie(_(\"--worktree needs a branch/worktree name\"));\n+\t}\n+\n \tif (filter.with_commit || filter.merge != REF_FILTER_MERGED_NONE || filter.points_at.nr)\n \t\tlist = 1;\n \n@@ -797,7 +806,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\tstrbuf_release(&buf);\n \t} else if (argc > 0 && argc <= 2) {\n \t\tstruct branch *branch = branch_get(argv[0]);\n-\t\tint branch_existed = 0, remote_tracking = 0;\n+\t\tint branch_existed = 0, remote_tracking = 0, res = 0;\n \t\tstruct strbuf buf = STRBUF_INIT;\n \n \t\tif (!strcmp(argv[0], \"HEAD\"))\n@@ -820,6 +829,17 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\tcreate_branch(head, argv[0], (argc == 2) ? argv[1] : head,\n \t\t\t      force, reflog, 0, quiet, track);\n \n+\t\tif (new_worktree) {\n+\t\t\tconst char *child_argv[] = {\n+\t\t\t\t\"worktree\", \"add\", NULL, NULL, NULL\n+\t\t\t};\n+\t\t\tchild_argv[2] = child_argv[3] = argv[0];\n+\t\t\tif ((res = run_command_v_opt(child_argv, RUN_GIT_CMD)))\n+\t\t\t\terror(_(\"Could not create worktree %s\"), argv[0]);\n+\t\t\telse\n+\t\t\t\tfprintf(stderr, _(\"New worktree set up at %s\\n\"), argv[0]);\n+\t\t}\n+\n \t\t/*\n \t\t * We only show the instructions if the user gave us\n \t\t * one branch which doesn't exist locally, but is the\n@@ -828,10 +848,13 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\tif (argc == 1 && track == BRANCH_TRACK_OVERRIDE &&\n \t\t    !branch_existed && remote_tracking) {\n \t\t\tfprintf(stderr, _(\"\\nIf you wanted to make '%s' track '%s', do this:\\n\\n\"), head, branch->name);\n+\t\t\tif (new_worktree)\n+\t\t\t\tfprintf(stderr, _(\"    # remove worktree %s/\\n\"), branch->name);\n \t\t\tfprintf(stderr, _(\"    git branch -d %s\\n\"), branch->name);\n \t\t\tfprintf(stderr, _(\"    git branch --set-upstream-to %s\\n\"), branch->name);\n \t\t}\n \n+\t\treturn res;\n \t} else\n \t\tusage_with_options(builtin_branch_usage, options);\n \n-- \n2.7.2.windows.1.8.g47d64e6.dirty\n"},{"id":"280549","messageId":"CACsJy8BA7-ev9wTt6K45TgiNxOaBUXbN1P03U4EUAzAPy=7Faw@mail.gmail.com","threadId":"41661","inReplyTo":"cover.1457609615.git.johannes.schindelin@gmx.de","subject":"Re: [PATCH 0/1] Introduce a way to create a branch and worktree at the same time","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-03-10T11:51:55Z","receivedAt":"2016-03-10T11:51:55Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Mar 10, 2016 at 6:34 PM, Johannes Schindelin\n<johannes.schindelin@gmx.de> wrote:\n> The invention of the `git worktree` command changed this developer's\n> working style dramatically. Rather than switching between branches all\n> the time, topic branches are created and checked out in newly-added\n> worktrees, to be reworked and refined until the topic branch is either\n> merged into `master` or abandoned.\n>\n> It gets rather tiresome, and also typo-prone, to call \"git branch xyz\n> upstream/master && git worktree add xyz xyz\" all the time.\n\nYou can actually do \"git worktree -b xyz xyz upstream/master\" for the\nsame effect. Maybe we can avoid \"xyz\" duplication with \"-b -\" or a new\noption name?\n\n> Hence this\n> proposal: \"git branch -w xyz upstream/master\" to do the same.\n>\n> The plan is to also support \"git branch -d -w xyz\" once the `git\n> worktree` command learned a `remove` (or `delete`) subcommand.\n\n\"git worktree remove\" is coming (will be resent after -rc period). And\nI agree it's convenient for it to remove the branch as well because\nthat happened to (and annoyed) me a few times. I still think it should\nbe centered around git-worktree than git-branch though.\n\n> One possible improvement would be to add \"/xyz/\" to the parent\n> repository's .git/info/exclude, but this developer hesitates to\n> introduce that feature without the \"delete\" counterpart: those exclude\n> entries would likely go stale very quickly. Besides, there might be a\n> plan in the working to exclude worktrees automagically?\n\nThat's needed because you add a worktree inside another worktree? I\nknow that feeling, but I've changed my layout from ~/w/git as main\nworktree (and ~/w/git/.git as repo) to ~/w/git as a non-worktree dir\nthat contains all worktrees, e.g. ~/w/git/reinclude-dir,\n~/w/git/worktree-config, ~/w/git/lmdb... My typical worktree add\ncommand is \"git worktree add ../<some-name>\" then move there and do\nstuff. No nested worktrees, no need to update exclude file (and no\nmessing up emacs' rgrep command, which does not understand .gitignore\nanyway)\n-- \nDuy\n"},{"id":"280550","messageId":"CACsJy8D7+sXF9gRj15kidgK_xzSVHqChSFdqHpJ3PwxMOw2rHA@mail.gmail.com","threadId":"41661","inReplyTo":"CACsJy8BA7-ev9wTt6K45TgiNxOaBUXbN1P03U4EUAzAPy=7Faw@mail.gmail.com","subject":"Re: [PATCH 0/1] Introduce a way to create a branch and worktree at the same time","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-03-10T11:59:11Z","receivedAt":"2016-03-10T11:59:11Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Mar 10, 2016 at 6:51 PM, Duy Nguyen <pclouds@gmail.com> wrote:\n>> It gets rather tiresome, and also typo-prone, to call \"git branch xyz\n>> upstream/master && git worktree add xyz xyz\" all the time.\n>\n> You can actually do \"git worktree -b xyz xyz upstream/master\" for the\n> same effect. Maybe we can avoid \"xyz\" duplication with \"-b -\" or a new\n> option name?\n\nAnother option is just do \"worktree -b xyz . upstream/master\"\n\nwhen the destination already exists and is a directory, the real\nworktree location is <dest>/<branch name>. Similar to \"mv abc def\"\nbecomes \"mv abc def/abc\" when def is already a directory.\n-- \nDuy\n"},{"id":"280554","messageId":"alpine.DEB.2.20.1603101417590.4690@virtualbox","threadId":"41661","inReplyTo":"CACsJy8BA7-ev9wTt6K45TgiNxOaBUXbN1P03U4EUAzAPy=7Faw@mail.gmail.com","subject":"Re: [PATCH 0/1] Introduce a way to create a branch and worktree at the same time","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-03-10T13:21:44Z","receivedAt":"2016-03-10T13:21:44Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Duy,\n\nOn Thu, 10 Mar 2016, Duy Nguyen wrote:\n\n> On Thu, Mar 10, 2016 at 6:34 PM, Johannes Schindelin\n> <johannes.schindelin@gmx.de> wrote:\n> > The invention of the `git worktree` command changed this developer's\n> > working style dramatically. Rather than switching between branches all\n> > the time, topic branches are created and checked out in newly-added\n> > worktrees, to be reworked and refined until the topic branch is either\n> > merged into `master` or abandoned.\n> >\n> > It gets rather tiresome, and also typo-prone, to call \"git branch xyz\n> > upstream/master && git worktree add xyz xyz\" all the time.\n> \n> You can actually do \"git worktree -b xyz xyz upstream/master\" for the\n> same effect. Maybe we can avoid \"xyz\" duplication with \"-b -\" or a new\n> option name?\n\nMy branch names are usually longer, such as pull-rebase-prefix. And I\nreally like the short 'n sweet \"git branch -w pull-rebase-prefix master\"\ninvocation.\n\n> > Hence this\n> > proposal: \"git branch -w xyz upstream/master\" to do the same.\n> >\n> > The plan is to also support \"git branch -d -w xyz\" once the `git\n> > worktree` command learned a `remove` (or `delete`) subcommand.\n> \n> \"git worktree remove\" is coming (will be resent after -rc period). And\n> I agree it's convenient for it to remove the branch as well because\n> that happened to (and annoyed) me a few times. I still think it should\n> be centered around git-worktree than git-branch though.\n\nGranted, \"git worktree remove\" should be the work horse. But why not have\ntwo ways to skin the same cat? I, again, would prefer the short 'n sweet\n\"git branch -d -w pull-rebase-prefix\" invocation.\n\n> > One possible improvement would be to add \"/xyz/\" to the parent\n> > repository's .git/info/exclude, but this developer hesitates to\n> > introduce that feature without the \"delete\" counterpart: those exclude\n> > entries would likely go stale very quickly. Besides, there might be a\n> > plan in the working to exclude worktrees automagically?\n> \n> That's needed because you add a worktree inside another worktree? I\n> know that feeling, but I've changed my layout from ~/w/git as main\n> worktree (and ~/w/git/.git as repo) to ~/w/git as a non-worktree dir\n> that contains all worktrees, e.g. ~/w/git/reinclude-dir,\n> ~/w/git/worktree-config, ~/w/git/lmdb... My typical worktree add\n> command is \"git worktree add ../<some-name>\" then move there and do\n> stuff. No nested worktrees, no need to update exclude file (and no\n> messing up emacs' rgrep command, which does not understand .gitignore\n> anyway)\n\nThis feels to me like it is working around the problem rather than solving\nit. My worktrees are inside the corresponding top-level project for a\nreason: I work with multiple projects, and having all of their worktrees\nin a single $HOME/w/ directory would be rather confusing to me.\n\nI really want to keep my Git worktrees inside /usr/src/git/ (in Git for\nWindows' SDK).\n\nCiao,\nDscho\n"},{"id":"280555","messageId":"alpine.DEB.2.20.1603101422190.4690@virtualbox","threadId":"41661","inReplyTo":"CACsJy8D7+sXF9gRj15kidgK_xzSVHqChSFdqHpJ3PwxMOw2rHA@mail.gmail.com","subject":"Re: [PATCH 0/1] Introduce a way to create a branch and worktree at the same time","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-03-10T13:24:16Z","receivedAt":"2016-03-10T13:24:16Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Duy,\n\nOn Thu, 10 Mar 2016, Duy Nguyen wrote:\n\n> On Thu, Mar 10, 2016 at 6:51 PM, Duy Nguyen <pclouds@gmail.com> wrote:\n> >> It gets rather tiresome, and also typo-prone, to call \"git branch xyz\n> >> upstream/master && git worktree add xyz xyz\" all the time.\n> >\n> > You can actually do \"git worktree -b xyz xyz upstream/master\" for the\n> > same effect. Maybe we can avoid \"xyz\" duplication with \"-b -\" or a new\n> > option name?\n> \n> Another option is just do \"worktree -b xyz . upstream/master\"\n> \n> when the destination already exists and is a directory, the real\n> worktree location is <dest>/<branch name>. Similar to \"mv abc def\"\n> becomes \"mv abc def/abc\" when def is already a directory.\n\nHmm. That sounds too clever to me. It is clever, alright, but it is also\nconfusing: \"Wait, what? Where is my... Darn! It already existed! And now I\nhave my-cool-worktree/my-cool-worktree/! Blergh.\"\n\nPlease count that as mild opposition to that idea :-)\n\nCiao,\nDscho\n"},{"id":"280570","messageId":"CAPig+cTjD7=jkyvQLwUAec3gNjWLjizqaiKJTu6XbhXHDgF3GA@mail.gmail.com","threadId":"41661","inReplyTo":"CACsJy8BA7-ev9wTt6K45TgiNxOaBUXbN1P03U4EUAzAPy=7Faw@mail.gmail.com","subject":"Re: [PATCH 0/1] Introduce a way to create a branch and worktree at the same time","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2016-03-10T20:45:10Z","receivedAt":"2016-03-10T20:45:10Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Thu, Mar 10, 2016 at 6:51 AM, Duy Nguyen <pclouds@gmail.com> wrote:\n> On Thu, Mar 10, 2016 at 6:34 PM, Johannes Schindelin\n> <johannes.schindelin@gmx.de> wrote:\n>> The invention of the `git worktree` command changed this developer's\n>> working style dramatically. Rather than switching between branches all\n>> the time, topic branches are created and checked out in newly-added\n>> worktrees, to be reworked and refined until the topic branch is either\n>> merged into `master` or abandoned.\n>>\n>> It gets rather tiresome, and also typo-prone, to call \"git branch xyz\n>> upstream/master && git worktree add xyz xyz\" all the time.\n>\n> You can actually do \"git worktree -b xyz xyz upstream/master\" for the\n> same effect. Maybe we can avoid \"xyz\" duplication with \"-b -\" or a new\n> option name?\n\nThere's also the even shorter form:\n\n    git worktree add pull-rebase-prefix\n\nwhich creates both a branch and a worktree named \"pull-rebase-prefix\".\nThis assumes that you want the new branch based upon HEAD, which won't\nwork if your use-case is different and that you're not already at the\ndesired commit (\"origin/master\" in your example) when invoking the\ncommand, though.\n"},{"id":"280600","messageId":"CACsJy8AuBsF_rhuo_a_nqaVH1ApT3iAyozt1w2vkmvHmK17hZA@mail.gmail.com","threadId":"41661","inReplyTo":"alpine.DEB.2.20.1603101417590.4690@virtualbox","subject":"Re: [PATCH 0/1] Introduce a way to create a branch and worktree at the same time","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-03-11T00:56:36Z","receivedAt":"2016-03-11T00:56:36Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Mar 10, 2016 at 8:21 PM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> Hi Duy,\n>\n> On Thu, 10 Mar 2016, Duy Nguyen wrote:\n>\n>> On Thu, Mar 10, 2016 at 6:34 PM, Johannes Schindelin\n>> <johannes.schindelin@gmx.de> wrote:\n>> > The invention of the `git worktree` command changed this developer's\n>> > working style dramatically. Rather than switching between branches all\n>> > the time, topic branches are created and checked out in newly-added\n>> > worktrees, to be reworked and refined until the topic branch is either\n>> > merged into `master` or abandoned.\n>> >\n>> > It gets rather tiresome, and also typo-prone, to call \"git branch xyz\n>> > upstream/master && git worktree add xyz xyz\" all the time.\n>>\n>> You can actually do \"git worktree -b xyz xyz upstream/master\" for the\n>> same effect. Maybe we can avoid \"xyz\" duplication with \"-b -\" or a new\n>> option name?\n>\n> My branch names are usually longer, such as pull-rebase-prefix. And I\n> really like the short 'n sweet \"git branch -w pull-rebase-prefix master\"\n> invocation.\n>\n>> > Hence this\n>> > proposal: \"git branch -w xyz upstream/master\" to do the same.\n\nThis assumes the new worktree is always placed at `cwd`. Perhaps it's\ntoo specific?\n\n>> > The plan is to also support \"git branch -d -w xyz\" once the `git\n>> > worktree` command learned a `remove` (or `delete`) subcommand.\n>>\n>> \"git worktree remove\" is coming (will be resent after -rc period). And\n>> I agree it's convenient for it to remove the branch as well because\n>> that happened to (and annoyed) me a few times. I still think it should\n>> be centered around git-worktree than git-branch though.\n>\n> Granted, \"git worktree remove\" should be the work horse. But why not have\n> two ways to skin the same cat? I, again, would prefer the short 'n sweet\n> \"git branch -d -w pull-rebase-prefix\" invocation.\n\nIf you put effort into making it happen, I'm not stopping you :)\n\n>> > One possible improvement would be to add \"/xyz/\" to the parent\n>> > repository's .git/info/exclude, but this developer hesitates to\n>> > introduce that feature without the \"delete\" counterpart: those exclude\n>> > entries would likely go stale very quickly. Besides, there might be a\n>> > plan in the working to exclude worktrees automagically?\n>>\n>> That's needed because you add a worktree inside another worktree? I\n>> know that feeling, but I've changed my layout from ~/w/git as main\n>> worktree (and ~/w/git/.git as repo) to ~/w/git as a non-worktree dir\n>> that contains all worktrees, e.g. ~/w/git/reinclude-dir,\n>> ~/w/git/worktree-config, ~/w/git/lmdb... My typical worktree add\n>> command is \"git worktree add ../<some-name>\" then move there and do\n>> stuff. No nested worktrees, no need to update exclude file (and no\n>> messing up emacs' rgrep command, which does not understand .gitignore\n>> anyway)\n>\n> This feels to me like it is working around the problem rather than solving\n> it. My worktrees are inside the corresponding top-level project for a\n> reason: I work with multiple projects, and having all of their worktrees\n> in a single $HOME/w/ directory would be rather confusing to me.\n>\n> I really want to keep my Git worktrees inside /usr/src/git/ (in Git for\n> Windows' SDK).\n\nI avoided it because adapting git alone was not enough, emacs' rgrep\nis just an example that other tools may have problems with this setup\ntoo. But if you still want to make git exclude them, I think you\nshould hook into the submodule peeking code instead of updating\nexclude file. It sounds neater to me.\n\nBut if you go with exclude auto update, it's about time we introduce\nmultiple exclude files in $GIT_DIR/info. So you can separate auto\nstuff from manual exclude rules.\n-- \nDuy\n"},{"id":"280604","messageId":"CAHYJk3Sij4tH0i29Asahjj8KBdQj59jFRTCoYzO_XE_kt3SnDw@mail.gmail.com","threadId":"41661","inReplyTo":"alpine.DEB.2.20.1603101417590.4690@virtualbox","subject":"Re: [PATCH 0/1] Introduce a way to create a branch and worktree at the same time","fromName":"Mikael Magnusson","fromEmail":"mikachu@gmail.com","sentAt":"2016-03-11T02:57:12Z","receivedAt":"2016-03-11T02:57:12Z","isPatch":true,"sender":{"key":"mikachu@gmail.com","avatar":null},"body":"On Thu, Mar 10, 2016 at 2:21 PM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> Hi Duy,\n>\n> On Thu, 10 Mar 2016, Duy Nguyen wrote:\n>\n>> On Thu, Mar 10, 2016 at 6:34 PM, Johannes Schindelin\n>> <johannes.schindelin@gmx.de> wrote:\n>> > One possible improvement would be to add \"/xyz/\" to the parent\n>> > repository's .git/info/exclude, but this developer hesitates to\n>> > introduce that feature without the \"delete\" counterpart: those exclude\n>> > entries would likely go stale very quickly. Besides, there might be a\n>> > plan in the working to exclude worktrees automagically?\n>>\n>> That's needed because you add a worktree inside another worktree? I\n>> know that feeling, but I've changed my layout from ~/w/git as main\n>> worktree (and ~/w/git/.git as repo) to ~/w/git as a non-worktree dir\n>> that contains all worktrees, e.g. ~/w/git/reinclude-dir,\n>> ~/w/git/worktree-config, ~/w/git/lmdb... My typical worktree add\n>> command is \"git worktree add ../<some-name>\" then move there and do\n>> stuff. No nested worktrees, no need to update exclude file (and no\n>> messing up emacs' rgrep command, which does not understand .gitignore\n>> anyway)\n>\n> This feels to me like it is working around the problem rather than solving\n> it. My worktrees are inside the corresponding top-level project for a\n> reason: I work with multiple projects, and having all of their worktrees\n> in a single $HOME/w/ directory would be rather confusing to me.\n>\n> I really want to keep my Git worktrees inside /usr/src/git/ (in Git for\n> Windows' SDK).\n\nYou can have /usr/src/git/master, /usr/src/git/some-work-tree, etc,\nand /usr/src/git itself is not a git repository at all. That way\n/usr/src only has one git-related directory and no worktrees are\nnested. The only downside is if you work in master most of the time,\nyou have to type \"/master\" more. I think this is what Duy suggested\ntoo, but you interpreted it as having /usr/src/git-master,\n/usr/src/git-some-work-tree etc?\n\n-- \nMikael Magnusson\n"},{"id":"280608","messageId":"xmqqmvq5bjlc.fsf@gitster.mtv.corp.google.com","threadId":"41661","inReplyTo":"CACsJy8AuBsF_rhuo_a_nqaVH1ApT3iAyozt1w2vkmvHmK17hZA@mail.gmail.com","subject":"Re: [PATCH 0/1] Introduce a way to create a branch and worktree at the same time","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-03-11T06:43:27Z","receivedAt":"2016-03-11T06:43:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen <pclouds@gmail.com> writes:\n\n>> Granted, \"git worktree remove\" should be the work horse. But why not have\n>> two ways to skin the same cat? I, again, would prefer the short 'n sweet\n>> \"git branch -d -w pull-rebase-prefix\" invocation.\n>\n> If you put effort into making it happen, I'm not stopping you :)\n\nI actually would ;-)  If I had to choose between the two, I'd prefer\nto see this new feature as part of the \"worktree\" subcommand, simply\nbecause \"branch\" is a fairly basic feature that can be used by those\nwho are new to Git without knowing that the \"worktree\" feature even\nexists (hence not having to have one extra option description in its\ndocumentation that talks about \"worktree\" is a big plus).\n\nBut that is only if I had to choose between the two.\n\nPersonally, I think you are better off implementing this set of\nfeatures as a set of shell aliases (be it bash or tcsh).  For one\nthing, you are likely to want to \"chdir\" to the newly created\nworktree built for the branch (or an existing one for the named\nbranch) for the \"take me to a worktree to work on this branch\"\nfeature.  The last action you would want that command to take is to\ntake you there, and \"git anything\" subcommand would not let you do\nthat (unless you tell your users to run \"eval `git something`\", a\nway similar to \"ssh-agent -s\", that is).\n\nThat approach to implement the UI that directly faces the end users\nvia scripting would let your users choose layouts more flexibly.\nSome people may want a repository and its worktrees next to each\nother, some others may want the worktrees embedded inside the main\nrepository, yet some others may want layouts other than those two.\n"},{"id":"280709","messageId":"alpine.DEB.2.20.1603141445140.4690@virtualbox","threadId":"41661","inReplyTo":"CAHYJk3Sij4tH0i29Asahjj8KBdQj59jFRTCoYzO_XE_kt3SnDw@mail.gmail.com","subject":"Re: [PATCH 0/1] Introduce a way to create a branch and worktree at the same time","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-03-14T13:45:33Z","receivedAt":"2016-03-14T13:45:33Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Mikael,\n\nOn Fri, 11 Mar 2016, Mikael Magnusson wrote:\n\n> On Thu, Mar 10, 2016 at 2:21 PM, Johannes Schindelin\n> <Johannes.Schindelin@gmx.de> wrote:\n> > Hi Duy,\n> >\n> > On Thu, 10 Mar 2016, Duy Nguyen wrote:\n> >\n> >> On Thu, Mar 10, 2016 at 6:34 PM, Johannes Schindelin\n> >> <johannes.schindelin@gmx.de> wrote:\n> >> > One possible improvement would be to add \"/xyz/\" to the parent\n> >> > repository's .git/info/exclude, but this developer hesitates to\n> >> > introduce that feature without the \"delete\" counterpart: those exclude\n> >> > entries would likely go stale very quickly. Besides, there might be a\n> >> > plan in the working to exclude worktrees automagically?\n> >>\n> >> That's needed because you add a worktree inside another worktree? I\n> >> know that feeling, but I've changed my layout from ~/w/git as main\n> >> worktree (and ~/w/git/.git as repo) to ~/w/git as a non-worktree dir\n> >> that contains all worktrees, e.g. ~/w/git/reinclude-dir,\n> >> ~/w/git/worktree-config, ~/w/git/lmdb... My typical worktree add\n> >> command is \"git worktree add ../<some-name>\" then move there and do\n> >> stuff. No nested worktrees, no need to update exclude file (and no\n> >> messing up emacs' rgrep command, which does not understand .gitignore\n> >> anyway)\n> >\n> > This feels to me like it is working around the problem rather than solving\n> > it. My worktrees are inside the corresponding top-level project for a\n> > reason: I work with multiple projects, and having all of their worktrees\n> > in a single $HOME/w/ directory would be rather confusing to me.\n> >\n> > I really want to keep my Git worktrees inside /usr/src/git/ (in Git for\n> > Windows' SDK).\n> \n> You can have /usr/src/git/master, /usr/src/git/some-work-tree, etc,\n> and /usr/src/git itself is not a git repository at all. That way\n> /usr/src only has one git-related directory and no worktrees are\n> nested. The only downside is if you work in master most of the time,\n> you have to type \"/master\" more. I think this is what Duy suggested\n> too, but you interpreted it as having /usr/src/git-master,\n> /usr/src/git-some-work-tree etc?\n\nThat is a sensible workaround.\n\nThe question is: why do I need a workaround?\n\nCiao,\nDscho\n"},{"id":"280762","messageId":"alpine.DEB.2.20.1603150746490.4690@virtualbox","threadId":"41661","inReplyTo":"xmqqmvq5bjlc.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 0/1] Introduce a way to create a branch and worktree at the same time","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-03-15T06:53:41Z","receivedAt":"2016-03-15T06:53:41Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Thu, 10 Mar 2016, Junio C Hamano wrote:\n\n> Duy Nguyen <pclouds@gmail.com> writes:\n> \n> >> Granted, \"git worktree remove\" should be the work horse. But why not have\n> >> two ways to skin the same cat? I, again, would prefer the short 'n sweet\n> >> \"git branch -d -w pull-rebase-prefix\" invocation.\n> >\n> > If you put effort into making it happen, I'm not stopping you :)\n> \n> I actually would ;-)  If I had to choose between the two, I'd prefer\n> to see this new feature as part of the \"worktree\" subcommand, simply\n> because \"branch\" is a fairly basic feature that can be used by those\n> who are new to Git without knowing that the \"worktree\" feature even\n> exists (hence not having to have one extra option description in its\n> documentation that talks about \"worktree\" is a big plus).\n\nI, in contrast, think it woild make for an excellent way to let users who\nare in the dear need for the worktree feature (like myself) find out about\nit.\n\nNobody reads release notes, but at least some people read man pages.\n\n> Personally, I think you are better off implementing this set of\n> features as a set of shell aliases (be it bash or tcsh).\n\nTrue, if I was simply selfish, I would use shell aliases, too.\n\nBut I want others to benefit from my work, too, hence the patch.\n\n> That approach to implement the UI that directly faces the end users\n> via scripting would let your users choose layouts more flexibly.\n> Some people may want a repository and its worktrees next to each\n> other, some others may want the worktrees embedded inside the main\n> repository, yet some others may want layouts other than those two.\n\nHaving the worktree in a totally different location than the associated\nrepository is *very* confusing. Unless, that is, you work on a single\nproject, ever, of course, which is a luxury typically only awarded to\nmaintainers, albeit not this one.\n\nAs such, *recommending* to have it elsewhere really is nothing but a\nworkaround for some bugs that should still be squashed instead.\n\nCiao,\nDscho\n"},{"id":"280771","messageId":"CACsJy8B+c8=Y0Lb-TxjGF4689xP2Vyqjp4Q6CuffTLDWDMh3gg@mail.gmail.com","threadId":"41661","inReplyTo":"alpine.DEB.2.20.1603150746490.4690@virtualbox","subject":"Re: [PATCH 0/1] Introduce a way to create a branch and worktree at the same time","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-03-15T10:34:37Z","receivedAt":"2016-03-15T10:34:37Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Mar 15, 2016 at 1:53 PM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n>> That approach to implement the UI that directly faces the end users\n>> via scripting would let your users choose layouts more flexibly.\n>> Some people may want a repository and its worktrees next to each\n>> other, some others may want the worktrees embedded inside the main\n>> repository, yet some others may want layouts other than those two.\n>\n> Having the worktree in a totally different location than the associated\n> repository is *very* confusing.\n\nI disagree (unless I misunderstood you). One of the use cases I have\nfor multi worktree is move all repos to a central place. Remember the\n.git directory security bug? It would not happen if the repo is put\naway. And it would be easier to backup repo data too. Also, \"git\nworktree list\" is there to locate any worktree. I don't see why it's\nconfusing.\n-- \nDuy\n"},{"id":"280780","messageId":"alpine.DEB.2.20.1603151448220.4690@virtualbox","threadId":"41661","inReplyTo":"CACsJy8B+c8=Y0Lb-TxjGF4689xP2Vyqjp4Q6CuffTLDWDMh3gg@mail.gmail.com","subject":"Re: [PATCH 0/1] Introduce a way to create a branch and worktree at the same time","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-03-15T13:56:19Z","receivedAt":"2016-03-15T13:56:19Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Duy,\n\nOn Tue, 15 Mar 2016, Duy Nguyen wrote:\n\n> On Tue, Mar 15, 2016 at 1:53 PM, Johannes Schindelin\n> <Johannes.Schindelin@gmx.de> wrote:\n> >> That approach to implement the UI that directly faces the end users\n> >> via scripting would let your users choose layouts more flexibly.\n> >> Some people may want a repository and its worktrees next to each\n> >> other, some others may want the worktrees embedded inside the main\n> >> repository, yet some others may want layouts other than those two.\n> >\n> > Having the worktree in a totally different location than the associated\n> > repository is *very* confusing.\n> \n> I disagree (unless I misunderstood you).\n\nHow is it not confusing having all of your worktrees, no matter whether\nthey connect to git.git, to git-for-windows/build-extra.git, to\nAlexpux/MSYS2-packages.git, to cygwin.git, to curl/curl.git, to\nwhatever.git inside $HOME/worktrees/?\n\nI tell you how it is not confusing. It is not confusing by artificially\nre-creating the hierarchy inside the $HOME/worktrees/ directory.\n\nAnd you only need to re-create the hierarchy because, you guessed it, you\ntried to disconnect the worktrees from their repositories.\n\nSo it is nothing but a bad old workaround, is what it is.\n\n> One of the use cases I have for multi worktree is move all repos to a\n> central place. Remember the .git directory security bug?\n\nI remember.\n\n> It would not happen if the repo is put away.\n\nSure. And with the repository being put elsewhere, you also buy the tedium\nto no longer be able to simply \"less .git/rebase-apply/patch\". Which I\nhave to type *a lot*. You win some, you lose some. If you ask me, you lose\nsome more, but in some cases that is worth it.\n\n> And it would be easier to backup repo data too. Also, \"git worktree\n> list\" is there to locate any worktree. I don't see why it's confusing.\n\nYeah, it is clear to me now that you do not find it confusing. Even if I\nfind that fact in and of itself confusing, because it is very, very\nconfusing to me to have the repository so far away from my worktree as to\nforget where it actually is, opening the door real wide for trouble e.g.\nby archiving my repository behind my worktree's back.\n\nYou win some, you lose some. I am simply not prepared to lose *that* much.\nMy worktrees will stay inside my originally checked out working directory,\nthankyouverymuch.\n\nCiao,\nDscho\n"},{"id":"280781","messageId":"CACsJy8A8OPZZnLs7dydvLMHz_CpU0xTaAAgmO9Vn2mABRywD6Q@mail.gmail.com","threadId":"41661","inReplyTo":"alpine.DEB.2.20.1603151448220.4690@virtualbox","subject":"Re: [PATCH 0/1] Introduce a way to create a branch and worktree at the same time","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-03-15T14:07:01Z","receivedAt":"2016-03-15T14:07:01Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Mar 15, 2016 at 8:56 PM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> Sure. And with the repository being put elsewhere, you also buy the tedium\n> to no longer be able to simply \"less .git/rebase-apply/patch\". Which I\n> have to type *a lot*. You win some, you lose some. If you ask me, you lose\n> some more, but in some cases that is worth it.\n\nIf you start to use git-worktree, you'll need to type even longer. I\nnotice I do and am seriously considering an alias of `git rev-parse\n--git-path rebase-apply/patch` to type less temporarily. But this is\nthe lack of proper UI. \"git rebase\" should provide a way to look at\nthis file (and maybe some others too). I just don't know what the\noption would be and how we align it with git-am, which shares this\nsame problem.\n-- \nDuy\n"},{"id":"280837","messageId":"56E87337.3040609@kdbg.org","threadId":"41661","inReplyTo":"CAHYJk3Sij4tH0i29Asahjj8KBdQj59jFRTCoYzO_XE_kt3SnDw@mail.gmail.com","subject":"Re: [PATCH 0/1] Introduce a way to create a branch and worktree at the same time","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2016-03-15T20:40:23Z","receivedAt":"2016-03-15T20:40:23Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 11.03.2016 um 03:57 schrieb Mikael Magnusson:\n> You can have /usr/src/git/master, /usr/src/git/some-work-tree, etc,\n> and /usr/src/git itself is not a git repository at all. That way\n> /usr/src only has one git-related directory and no worktrees are\n> nested.\n\nI started using separate worktrees recently, and I chose the layout you \nsketch here. I didn't ask someone or read any documentation to find out \nabout a recommended layout. I chose the layout because it felt the most \nnatural.\n\nNever in my life would I have considered nesting worktrees inside other \nworktrees.\n\n-- Hannes\n"}]}