{"thread":{"id":"38237","subject":"Re: [PATCH] git-new-workdir: support submodules","startedAt":"2014-12-23T21:51:40Z","lastAt":"2015-01-28T20:18:37Z","messageCount":11,"participants":["Craig Silverstein","Junio C Hamano","Jens Lehmann","Duy Nguyen"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"254053","messageId":"CAGXKyzHoLLgkXk0X4UVtLBEryqsHriKmmO5+2iVWk3mR8y7=Hw@mail.gmail.com","threadId":"38237","inReplyTo":null,"subject":"Re: [PATCH] git-new-workdir: support submodules","fromName":"Craig Silverstein","fromEmail":"csilvers@khanacademy.org","sentAt":"2014-12-23T21:51:40Z","receivedAt":"2014-12-23T21:51:40Z","isPatch":true,"sender":{"key":"csilvers@khanacademy.org","avatar":null},"body":"[Ack, I forgot to cc myself on the original patch so now I can't reply\nto it normally. Hopefully my workaround doesn't mess up the threading\ntoo badly.]\n\nJunio C Hamano pobox.com> writes:\n>\n> Hmmmm, does that mean that the submodule S in the original\n> repository O's working tree and its checkout in the secondary\n> working tree W created from O using git-new-workdir share the same\n> repository location? More specifically:\n>\n> O/.git/ - original repository\n> O/.git/index - worktree state in O\n> O/S - submodule S's checkout in O\n> O/S/.git - a gitfile pointing to O/.git/modules/S\n> O/.git/modules/S - submodule S's repository contents\n> O/.git/modules/S/config - submodule S's config\n>\n> W/.git/ - secondary working tree\n> W/.git/config - symlink to O/.git/config\n> W/.git/index - worktree state in W (independent of O)\n> W/S - submodule S's checkout in W (independent of O)\n> W/S/.git - a gitfile pointing to O/.git/modules/S\n\nRight until the last line. The .git file holds a relative path (at\nleast, it always does in my experience), so W/S/.git will point to\nW/.git/modules/S.\n\nAlso, to complete the story, my changes sets the following:\n\n W/.git/modules/S - secondary working tree for S\n W/.git/modules/S/config - symlink to O/.git/modules/S/config\n W/.git/modules/S/index - worktree state in W's S\n(independent of O and O's S)\n\n> Doesn't a submodule checkout keep some state tied to the working\n> tree in its repository configuration file?\n\nDo you mean, in 'config' itself? If so, I don't see it. (Though it's\npossible there are ways to use submodules that do keep working-tree\nstate in the config file, and we just happen not to use those ways.)\nHere's what my webapp/.git/modules/khan-exercises/config looks like:\n---\n[core]\n repositoryformatversion = 0\n filemode = true\n bare = false\n logallrefupdates = true\n worktree = ../../../khan-exercises\n[remote \"origin\"]\n url = http://github.com/Khan/khan-exercises.git\n fetch = +refs/heads/*:refs/remotes/origin/*\n[branch \"master\"]\n remote = origin\n merge = refs/heads/master\n rebase = true\n[submodule \"test/qunit\"]\n url = https://github.com/jquery/qunit.git\n--\n\nThe only thing that seems vaguely working-tree related is the\n'worktree' field, which is the field that motivated me to set up my\npatch the way it is.\n\n> Wouldn't this change\n> introduce problems by sharing O/.git/modules/S/config between the\n> two checkouts?\n\nIt's true that this change does result in sharing that file, so if\nthat's problematic then you're right. I'm afraid I don't know all the\nthings that can go into a submodule config file.\n\n(There are other things I don't know as well, such as: do we see .git\nfiles with 'gitdir: ...' contents only for submodules, or are there\nother ways to create them as well? Are 'gitdir' paths always\nrelative? Are there special files in .git (or rather .git/modules/S)\nthat exist only for submodules and not for 'normal' repos, that we\nneed to worry about symlinking? I apologize for not knowing all these\ngit internals, and hope you guys can help point out any gaps that\naffect this patch!)\n\ncraig\n"},{"id":"255244","messageId":"CAGXKyzEwAjCNTxRtjSuFh9b6BzzOYKOQryKtXBGY3_hkkFvyVw@mail.gmail.com","threadId":"38237","inReplyTo":"CAGXKyzHoLLgkXk0X4UVtLBEryqsHriKmmO5+2iVWk3mR8y7=Hw@mail.gmail.com","subject":"Re: [PATCH] git-new-workdir: support submodules","fromName":"Craig Silverstein","fromEmail":"csilvers@khanacademy.org","sentAt":"2015-01-24T00:48:40Z","receivedAt":"2015-01-24T00:48:40Z","isPatch":true,"sender":{"key":"csilvers@khanacademy.org","avatar":null},"body":"Ping! (now that the holidays are past)\n\ncraig\n\nOn Tue, Dec 23, 2014 at 1:51 PM, Craig Silverstein\n wrote:\n> [Ack, I forgot to cc myself on the original patch so now I can't reply\n> to it normally. Hopefully my workaround doesn't mess up the threading\n> too badly.]\n>\n> Junio C Hamano pobox.com> writes:\n>>\n>> Hmmmm, does that mean that the submodule S in the original\n>> repository O's working tree and its checkout in the secondary\n>> working tree W created from O using git-new-workdir share the same\n>> repository location? More specifically:\n>>\n>> O/.git/ - original repository\n>> O/.git/index - worktree state in O\n>> O/S - submodule S's checkout in O\n>> O/S/.git - a gitfile pointing to O/.git/modules/S\n>> O/.git/modules/S - submodule S's repository contents\n>> O/.git/modules/S/config - submodule S's config\n>>\n>> W/.git/ - secondary working tree\n>> W/.git/config - symlink to O/.git/config\n>> W/.git/index - worktree state in W (independent of O)\n>> W/S - submodule S's checkout in W (independent of O)\n>> W/S/.git - a gitfile pointing to O/.git/modules/S\n>\n> Right until the last line. The .git file holds a relative path (at\n> least, it always does in my experience), so W/S/.git will point to\n> W/.git/modules/S.\n>\n> Also, to complete the story, my changes sets the following:\n>\n> W/.git/modules/S - secondary working tree for S\n> W/.git/modules/S/config - symlink to O/.git/modules/S/config\n> W/.git/modules/S/index - worktree state in W's S\n> (independent of O and O's S)\n>\n>> Doesn't a submodule checkout keep some state tied to the working\n>> tree in its repository configuration file?\n>\n> Do you mean, in 'config' itself? If so, I don't see it. (Though it's\n> possible there are ways to use submodules that do keep working-tree\n> state in the config file, and we just happen not to use those ways.)\n> Here's what my webapp/.git/modules/khan-exercises/config looks like:\n> ---\n> [core]\n> repositoryformatversion = 0\n> filemode = true\n> bare = false\n> logallrefupdates = true\n> worktree = ../../../khan-exercises\n> [remote \"origin\"]\n> url = http://github.com/Khan/khan-exercises.git\n> fetch = +refs/heads/*:refs/remotes/origin/*\n> [branch \"master\"]\n> remote = origin\n> merge = refs/heads/master\n> rebase = true\n> [submodule \"test/qunit\"]\n> url = https://github.com/jquery/qunit.git\n> --\n>\n> The only thing that seems vaguely working-tree related is the\n> 'worktree' field, which is the field that motivated me to set up my\n> patch the way it is.\n>\n>> Wouldn't this change\n>> introduce problems by sharing O/.git/modules/S/config between the\n>> two checkouts?\n>\n> It's true that this change does result in sharing that file, so if\n> that's problematic then you're right. I'm afraid I don't know all the\n> things that can go into a submodule config file.\n>\n> (There are other things I don't know as well, such as: do we see .git\n> files with 'gitdir: ...' contents only for submodules, or are there\n> other ways to create them as well? Are 'gitdir' paths always\n> relative? Are there special files in .git (or rather .git/modules/S)\n> that exist only for submodules and not for 'normal' repos, that we\n> need to worry about symlinking? I apologize for not knowing all these\n> git internals, and hope you guys can help point out any gaps that\n> affect this patch!)\n>\n> craig\n"},{"id":"255247","messageId":"xmqqegqlnelu.fsf@gitster.dls.corp.google.com","threadId":"38237","inReplyTo":"CAGXKyzEwAjCNTxRtjSuFh9b6BzzOYKOQryKtXBGY3_hkkFvyVw@mail.gmail.com","subject":"Re: [PATCH] git-new-workdir: support submodules","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-01-24T01:37:17Z","receivedAt":"2015-01-24T01:37:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Craig Silverstein writes:\n\n>>> Doesn't a submodule checkout keep some state tied to the working\n>>> tree in its repository configuration file?\n>>\n>> Do you mean, in 'config' itself? If so, I don't see it. (Though it's\n>> possible there are ways to use submodules that do keep working-tree\n>> state in the config file, and we just happen not to use those ways.)\n>> Here's what my webapp/.git/modules/khan-exercises/config looks like:\n>> ---\n>> [core]\n>> repositoryformatversion = 0\n>> filemode = true\n>> bare = false\n>> logallrefupdates = true\n>> worktree = ../../../khan-exercises\n>> [remote \"origin\"]\n>> url = http://github.com/Khan/khan-exercises.git\n>> fetch = +refs/heads/*:refs/remotes/origin/*\n>> [branch \"master\"]\n>> remote = origin\n>> merge = refs/heads/master\n>> rebase = true\n>> [submodule \"test/qunit\"]\n>> url = https://github.com/jquery/qunit.git\n>> --\n>>\n>> The only thing that seems vaguely working-tree related is the\n>> 'worktree' field, which is the field that motivated me to set up my\n>> patch the way it is.\n\nThat is the location of the working tree of the top-level\nsuperproject. Tied to the state of the submodule working tree\nappear in [submodule \"test/qunit\"] part.\n\nIn one new-workdir checkout, that submodule may be \"submodule\ninit\"ed, while another one, it may not be.\n\nOr one new-workdir checkout's branch may check out a top-level\nproject from today while the other one may have a top-level project\nfrom two years ago, and between these two checkouts of the top-level\nproject, the settings of submodule.\"test/qunit\".* variables may have\nto be different (perhaps even URL may have to point at two different\nrepositories, one historical one to grab the state two years ago,\nthe other current one).\n\nSo sharing config between top-level checkouts may not be enough to\n\"support submodules\" (the patch title).\n"},{"id":"255255","messageId":"CAGXKyzEPWrbRFOhvCBm=2Z50zso85G50z-nLd_wyzyeEADQSmw@mail.gmail.com","threadId":"38237","inReplyTo":"xmqqegqlnelu.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] git-new-workdir: support submodules","fromName":"Craig Silverstein","fromEmail":"csilvers@khanacademy.org","sentAt":"2015-01-25T01:47:35Z","receivedAt":"2015-01-25T01:47:35Z","isPatch":true,"sender":{"key":"csilvers@khanacademy.org","avatar":null},"body":"} Or one new-workdir checkout's branch may check out a top-level\n} project from today while the other one may have a top-level project\n} from two years ago,\n\nThis is also true, but just as much a problem with the 'git\nnew-workdir' script as it existed before my change. It already\nsymlinks the top-level .git/config directory, which lists a remote,\nsubmodules, and many other things. Does symlinking the config file\nfor submodules add any new wrinkles, that symlinking the config file\nfor the top-level repository does not?\n\ncraig\n\nOn Fri, Jan 23, 2015 at 5:37 PM, Junio C Hamano wrote:\n> Craig Silverstein writes:\n>\n>>>> Doesn't a submodule checkout keep some state tied to the working\n>>>> tree in its repository configuration file?\n>>>\n>>> Do you mean, in 'config' itself? If so, I don't see it. (Though it's\n>>> possible there are ways to use submodules that do keep working-tree\n>>> state in the config file, and we just happen not to use those ways.)\n>>> Here's what my webapp/.git/modules/khan-exercises/config looks like:\n>>> ---\n>>> [core]\n>>> repositoryformatversion = 0\n>>> filemode = true\n>>> bare = false\n>>> logallrefupdates = true\n>>> worktree = ../../../khan-exercises\n>>> [remote \"origin\"]\n>>> url = http://github.com/Khan/khan-exercises.git\n>>> fetch = +refs/heads/*:refs/remotes/origin/*\n>>> [branch \"master\"]\n>>> remote = origin\n>>> merge = refs/heads/master\n>>> rebase = true\n>>> [submodule \"test/qunit\"]\n>>> url = https://github.com/jquery/qunit.git\n>>> --\n>>>\n>>> The only thing that seems vaguely working-tree related is the\n>>> 'worktree' field, which is the field that motivated me to set up my\n>>> patch the way it is.\n>\n> That is the location of the working tree of the top-level\n> superproject. Tied to the state of the submodule working tree\n> appear in [submodule \"test/qunit\"] part.\n>\n> In one new-workdir checkout, that submodule may be \"submodule\n> init\"ed, while another one, it may not be.\n>\n> Or one new-workdir checkout's branch may check out a top-level\n> project from today while the other one may have a top-level project\n> from two years ago, and between these two checkouts of the top-level\n> project, the settings of submodule.\"test/qunit\".* variables may have\n> to be different (perhaps even URL may have to point at two different\n> repositories, one historical one to grab the state two years ago,\n> the other current one).\n>\n> So sharing config between top-level checkouts may not be enough to\n> \"support submodules\" (the patch title).\n"},{"id":"255282","messageId":"xmqqa916nq4p.fsf@gitster.dls.corp.google.com","threadId":"38237","inReplyTo":"CAGXKyzEPWrbRFOhvCBm=2Z50zso85G50z-nLd_wyzyeEADQSmw@mail.gmail.com","subject":"Re: [PATCH] git-new-workdir: support submodules","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-01-26T04:05:10Z","receivedAt":"2015-01-26T04:05:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Craig Silverstein writes:\n\n> } Or one new-workdir checkout's branch may check out a top-level\n> } project from today while the other one may have a top-level project\n> } from two years ago,\n>\n> This is also true, but just as much a problem with the 'git\n> new-workdir' script as it existed before my change. It already\n> symlinks the top-level .git/config directory, which lists a remote,\n> submodules, and many other things. Does symlinking the config file\n> for submodules add any new wrinkles, that symlinking the config file\n> for the top-level repository does not?\n\nThe update under discussion is labeled as \"support submodules\";\npresumably the only reason that such an update is good is because it\nwill fix existing problems that makes the use of the script break\nwhen submodules are involved --- submodules are not supported with\nthe current code, and this patch fixes the code to support it.\n\nBut then, you are saying that the update does not fix these existing\nissues around submodule support. So...?\n"},{"id":"255285","messageId":"CAGXKyzEYVsz-nRs52pTKo+6JLBiO9daU_C3qev3H43=Vzuygiw@mail.gmail.com","threadId":"38237","inReplyTo":"xmqqa916nq4p.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] git-new-workdir: support submodules","fromName":"Craig Silverstein","fromEmail":"csilvers@khanacademy.org","sentAt":"2015-01-26T04:57:49Z","receivedAt":"2015-01-26T04:57:49Z","isPatch":true,"sender":{"key":"csilvers@khanacademy.org","avatar":null},"body":"> But then, you are saying that the update does not fix these existing\n> issues around submodule support. So...?\n\nI guess my point is that the existing contrib script has proven to be\nuseful to people, even though it imposes these constraints on clients\nwrt the config file (namely, you can't have multiple workdirs that\nneed different values in the config file). This patch, in adding\nsubmodule support, I expect would be similarly useful to people even\nthough it, also, imposes those same constraints to the submodule's\nconfig files.\n\nI guess you'd rather see these config file issues fixed for all use\ncases? If so, I'm probably not the right person since I do not know\nenough about how config files are used in git -- I fear any changes I\nmade would make some things worse for (some) existing clients of the\nscript, which is not what I want. It sounds like this functionality\nis being reimplemented in git proper in any case, so perhaps it's best\njust to wait for that. I don't know what its submodule support will\nbe, though.\n\ncraig\n"},{"id":"255286","messageId":"xmqqtwzem776.fsf@gitster.dls.corp.google.com","threadId":"38237","inReplyTo":"CAGXKyzEYVsz-nRs52pTKo+6JLBiO9daU_C3qev3H43=Vzuygiw@mail.gmail.com","subject":"Re: [PATCH] git-new-workdir: support submodules","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-01-26T05:39:25Z","receivedAt":"2015-01-26T05:39:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Craig Silverstein writes:\n\n> This patch, in adding submodule support, I expect would be\n> similarly useful to people even though it, also, imposes those\n> same constraints to the submodule's config files.\n\nI would expect that you would see exactly the same issue with Duy's\nmultiple work tree series. This is not limited to new-workdir.\n\nThe right way to look at this is to fix what \"git submodule\" does;\nits use of \"config\" that is shared across branches is the root cause\nof the trouble. No other part of Git keeps data that needs to be\nper-branch (or more specifically \"tied to the working tree state\")\nin .git/config in such a way that leaving it stale when the working\ntree state changes breaks the system.\n\nOne way to do so might be to move the bits it stores in the config\nfile to somewhere else that is more closely tied to the checkout\nstate and handle that similar to .git/index and .git/HEAD when it\ncomes to multiple work-trees.\n"},{"id":"255338","messageId":"54C7CC6D.80906@web.de","threadId":"38237","inReplyTo":"xmqqtwzem776.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] git-new-workdir: support submodules","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2015-01-27T17:35:41Z","receivedAt":"2015-01-27T17:35:41Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 26.01.2015 um 06:39 schrieb Junio C Hamano:\n> Craig Silverstein writes:\n>\n>> This patch, in adding submodule support, I expect would be\n>> similarly useful to people even though it, also, imposes those\n>> same constraints to the submodule's config files.\n>\n> I would expect that you would see exactly the same issue with Duy's\n> multiple work tree series. This is not limited to new-workdir.\n>\n> The right way to look at this is to fix what \"git submodule\" does;\n> its use of \"config\" that is shared across branches is the root cause\n> of the trouble. No other part of Git keeps data that needs to be\n> per-branch (or more specifically \"tied to the working tree state\")\n> in .git/config in such a way that leaving it stale when the working\n> tree state changes breaks the system.\n\nI'm not sure what submodule config shared across branches you are\nreferring to here, the only two things that submodules by default\nstore in .git/config are the url (to mark the submodule initialized)\nand the update setting (which I believe should be copied there in\nthe first place, but changing that in a correct and backwards\ncompatible would take some effort). This means you'll init (or\ndeinit) a submodule in all multiple worktrees at the same time, but\nhaving the url setting in .git/config is a feature, not a bug.\n\nAnd if you are talking about the core.worktree setting in\n.git/modules//config, I proposed way to get rid of\nthat when we moved the submodule .git directory there (but that\nwasn't accepted):\n\n http://permalink.gmane.org/gmane.comp.version-control.git/188007\n\nAdditionally I suspect submodules are just the first to suffer,\nother worktree specific config (like e.g. EOL settings) affecting\nall multiple worktrees at the same time when changed in a single\nworktree might easily confuse other users too.\n\n> One way to do so might be to move the bits it stores in the config\n> file to somewhere else that is more closely tied to the checkout\n> state and handle that similar to .git/index and .git/HEAD when it\n> comes to multiple work-trees.\n\nYup, the idea of separating config entries into worktree and repo\nspecific files sounds like the solution for these problems.\n"},{"id":"255391","messageId":"20150128105007.GA761@lanh","threadId":"38237","inReplyTo":"54C7CC6D.80906@web.de","subject":"Re: [PATCH] git-new-workdir: support submodules","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2015-01-28T10:50:07Z","receivedAt":"2015-01-28T10:50:07Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Jan 27, 2015 at 06:35:41PM +0100, Jens Lehmann wrote:\n> > One way to do so might be to move the bits it stores in the config\n> > file to somewhere else that is more closely tied to the checkout\n> > state and handle that similar to .git/index and .git/HEAD when it\n> > comes to multiple work-trees.\n> \n> Yup, the idea of separating config entries into worktree and repo\n> specific files sounds like the solution for these problems.\n\nOK, would this work? This PoC patch adds a config key namespace\nlocal.* that is written to $GIT_DIR/config.local instead of\n$GIT_DIR/config (I still need to ban local.* in global config\nfiles). This config.local is loaded togethr with $GIT_DIR/config.\n\nFor nd/multiple-work-trees we can transparently map\n$GIT_DIR/config.local to $SUPER/worktrees//config.local. For\ngit-new-workdir.sh, perhaps we can teach include.path to make\nconfig.local path relative to where the config symlink is, not where\nthe symlink target is.\n\nWe can then teach setup.c to read local.core.worktree if core.worktree\nis not present, and more apdation in git-submodule.sh.. I don't expect\nbig changes because git-submodule.sh just needs to read some other\nconfig keys and dont need to care if git-new-workdir.sh or\nnd/multiple-work-trees is being used.\n\n-- 8< --\ndiff --git a/config.c b/config.c\nindex 752e2e2..237bd8e 100644\n--- a/config.c\n+++ b/config.c\n@@ -1177,6 +1177,15 @@ int git_config_system(void)\n \treturn !git_env_bool(\"GIT_CONFIG_NOSYSTEM\", 0);\n }\n \n+static int config_local_filter(const char *var, const char *value, void *data)\n+{\n+\tstruct config_include_data *inc = data;\n+\n+\tif (!starts_with(var, \"local.\"))\n+\t\treturn error(\"$GIT_DIR/config.local can only contain local.*\");\n+\treturn inc->fn(var, value, inc->data);\n+}\n+\n int git_config_early(config_fn_t fn, void *data, const char *repo_config)\n {\n \tint ret = 0, found = 0;\n@@ -1202,8 +1211,19 @@ int git_config_early(config_fn_t fn, void *data, const char *repo_config)\n \t}\n \n \tif (repo_config && !access_or_die(repo_config, R_OK, 0)) {\n+\t\tchar *wt_config;\n \t\tret += git_config_from_file(fn, repo_config, data);\n \t\tfound += 1;\n+\t\twt_config = git_pathdup(\"config.local\");\n+\t\tif (!access_or_die(wt_config, R_OK, 0)) {\n+\t\t\tstruct config_include_data inc = CONFIG_INCLUDE_INIT;\n+\t\t\tinc.fn = fn;\n+\t\t\tinc.data = data;\n+\t\t\tret += git_config_from_file(config_local_filter,\n+\t\t\t\t\t\t wt_config, &inc);\n+\t\t\tfound += 1;\n+\t\t}\n+\t\tfree(wt_config);\n \t}\n \n \tswitch (git_config_from_parameters(fn, data)) {\n@@ -1942,8 +1962,12 @@ int git_config_set_multivar_in_file(const char *config_filename,\n \n \tstore.multi_replace = multi_replace;\n \n-\tif (!config_filename)\n-\t\tconfig_filename = filename_buf = git_pathdup(\"config\");\n+\tif (!config_filename) {\n+\t\tif (starts_with(key, \"local.\"))\n+\t\t\tconfig_filename = filename_buf = git_pathdup(\"config.local\");\n+\t\telse\n+\t\t\tconfig_filename = filename_buf = git_pathdup(\"config\");\n+\t}\n \n \t/*\n \t * The lock serves a purpose in addition to locking: the new\n-- 8< --\n"},{"id":"255392","messageId":"CACsJy8C1zBawTbeNcr+JtzTwHupb8jpivL-8Tvr=zjAAUhMLLw@mail.gmail.com","threadId":"38237","inReplyTo":"20150128105007.GA761@lanh","subject":"Re: [PATCH] git-new-workdir: support submodules","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2015-01-28T10:53:43Z","receivedAt":"2015-01-28T10:53:43Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Jan 28, 2015 at 5:50 PM, Duy Nguyen wrote:\n> For git-new-workdir.sh, perhaps we can teach include.path to make\n> config.local path relative to where the config symlink is, not where\n> the symlink target is.\n\nIgnore this part. I originally wanted to use include.path to load\nconfig.local, but there was an easier way. With this patch, I think\nconfig.local is already per worktree that is created by\ngit-new-workdir.sh.\n-- \nDuy\n"},{"id":"255363","messageId":"xmqqbnlihd5u.fsf@gitster.dls.corp.google.com","threadId":"38237","inReplyTo":"CACsJy8C1zBawTbeNcr+JtzTwHupb8jpivL-8Tvr=zjAAUhMLLw@mail.gmail.com","subject":"Re: [PATCH] git-new-workdir: support submodules","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-01-28T20:18:37Z","receivedAt":"2015-01-28T20:18:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen writes:\n\n> On Wed, Jan 28, 2015 at 5:50 PM, Duy Nguyen wrote:\n>> For git-new-workdir.sh, perhaps we can teach include.path to make\n>> config.local path relative to where the config symlink is, not where\n>> the symlink target is.\n>\n> Ignore this part. I originally wanted to use include.path to load\n> config.local, but there was an easier way. With this patch, I think\n> config.local is already per worktree that is created by\n> git-new-workdir.sh.\n\nI think this may give us a cleaner approach to support a \"keep\nmultiple working trees from the same project that are configured\ndifferently\" setting.\n\nI am not sure how well it meshes to call this as \".local\" with the\n\"--local\" option of \"git config\" (read: \"local\" is a loaded word,\nand the way we have used it have been \"per repository\", but now you\nare using it to mean \"per working tree\" that is finer grained),\nthough.\n\nI hope that there aren't people that are crazy enough to bind the\nsame repository to two different places in the top-level project,\nand insist that we (re)use the submodule repository ;-).\n"}]}