{"thread":{"id":"30297","subject":"contrib/workdir/git-new-workdir broken in 1.7.10 after introducing gitfiles","startedAt":"2012-04-20T20:16:31Z","lastAt":"2012-04-22T18:58:56Z","messageCount":7,"participants":["Antonin Hildebrand","Jens Lehmann","Junio C Hamano","Mark Levedahl"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"189777","messageId":"CAHsq6J6JOTYfEtK0Z=_qfMFf9N1DWQ4zx46YhBbNu-1gEMyfog@mail.gmail.com","threadId":"30297","inReplyTo":null,"subject":"contrib/workdir/git-new-workdir broken in 1.7.10 after introducing gitfiles","fromName":"Antonin Hildebrand","fromEmail":"antonin@hildebrand.cz","sentAt":"2012-04-20T20:16:31Z","receivedAt":"2012-04-20T20:16:31Z","isPatch":false,"sender":{"key":"antonin@hildebrand.cz","avatar":null},"body":"Hi there,\n\nI'm just solving same problem as described here in the question:\nhttp://stackoverflow.com/questions/4115817/duplicate-submodules-with-git\n\nI wanted to try proposed solution, but git-new-workdir does not work\nin latest release 1.7.10.\n\nThe problem are plaintext .git files pointing to the root\n\"superproject\" .git directory. The script has not been updated to deal\nwith this new situation.\n\nthanks,\nAntonin\n"},{"id":"189811","messageId":"4F930043.1080506@web.de","threadId":"30297","inReplyTo":"CAHsq6J6JOTYfEtK0Z=_qfMFf9N1DWQ4zx46YhBbNu-1gEMyfog@mail.gmail.com","subject":"Re: contrib/workdir/git-new-workdir broken in 1.7.10 after introducing gitfiles","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2012-04-21T18:45:23Z","receivedAt":"2012-04-21T18:45:23Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 20.04.2012 22:16, schrieb Antonin Hildebrand:\n> Hi there,\n> \n> I'm just solving same problem as described here in the question:\n> http://stackoverflow.com/questions/4115817/duplicate-submodules-with-git\n> \n> I wanted to try proposed solution, but git-new-workdir does not work\n> in latest release 1.7.10.\n> \n> The problem are plaintext .git files pointing to the root\n> \"superproject\" .git directory. The script has not been updated to deal\n> with this new situation.\n\nThe problem is not the gitfile, but the core.worktree setting. And\nI don't see how that script can be updated to deal with the new\nsituation. Since 1.7.8 the core.worktree setting is used to point\nfrom the submodules .git directory to its work tree. And as\ngit-new-worktree just links the config file, it inherits the\ncore.worktree setting too, so that will always point to the first\nwork tree even when in the new workdir. And if git-new-worktree\nwould change core.worktree, the first work tree will stop working.\n\nI'm not sure why git-new-workdir is used here anyways, the only reason\nI can think of is to save some disk space. So use a regular submodule\nthere and everything should work for you (at the expense of having the\nsame object store on disk twice).\n\nBut it seems like a check is missing in the git-new-workdir script if\nthe core.worktree setting is used, as it will never do what it is meant\nto when that is set and doesn't point to the target directory. Maybe\nsomething like the patch below?\n\nWhat I worry about is that after this change it will give users who\nfollow the above mentioned recipe a misleading advice, as following it\nwill make the first submodule stop working. But from the perspective of\ngit-new-workdir this change makes sense, and maybe we have to fix the\nstackoverflow recipe instead ... on the other hand, problems like this\ncould be the avoided if we'd use the \"if we reached thru a gitfile,\nthen the working tree is where you found that gitfile\" setup logic\noutlined in\nhttp://permalink.gmane.org/gmane.comp.version-control.git/188007\n\nOpinions?\n\n----8<-----\nSubject: [PATCH] git-new-workdir: Suggest unsetting the core.worktree setting\n\nLinking to a repository that has the core.worktree option set can only\nwork when that core.worktree setting already points to the new-workdir.\nIn all other cases strange things will happen, as new-workdir will be\noverridden by that setting.\n\nSo just die when that setting is found and tell the user why and that he\nshould remove it.\n\nReported-by: Antonin Hildebrand \nSigned-off-by: Jens Lehmann \n---\n contrib/workdir/git-new-workdir | 8 ++++++++\n 1 file changed, 8 insertions(+)\n\ndiff --git a/contrib/workdir/git-new-workdir b/contrib/workdir/git-new-workdir\nindex 75e8b25..90cc207 100755\n--- a/contrib/workdir/git-new-workdir\n+++ b/contrib/workdir/git-new-workdir\n@@ -41,6 +41,14 @@ then\n \t\t\" remove from \\\"$git_dir/config\\\" to use $0\"\n fi\n\n+# don't link to a repository that has core.worktree defined\n+coreworktree=$(git --git-dir=\"$git_dir\" config --get core.worktree)\n+if test -n \"$coreworktree\"\n+then\n+\tdie \"\\\"$git_dir\\\" has core.worktree set to \\\"$coreworktree\\\",\" \\\n+\t\t\" remove from \\\"$git_dir/config\\\" to use $0\"\n+fi\n+\n # don't link to a workdir\n if test -h \"$git_dir/config\"\n then\n-- \n1.7.10.208.gb5e6d\n"},{"id":"189813","messageId":"xmqq397wzwwd.fsf@junio.mtv.corp.google.com","threadId":"30297","inReplyTo":"4F930043.1080506@web.de","subject":"Re: contrib/workdir/git-new-workdir broken in 1.7.10 after introducing gitfiles","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-21T19:51:14Z","receivedAt":"2012-04-21T19:51:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann writes:\n\n> Opinions?\n>\n> ----8<-----\n> Subject: [PATCH] git-new-workdir: Suggest unsetting the core.worktree setting\n>\n> Linking to a repository that has the core.worktree option set can only\n> work when that core.worktree setting already points to the new-workdir.\n> In all other cases strange things will happen, as new-workdir will be\n> overridden by that setting.\n\nAs you analyzed correctly, core.worktree lets a GIT_DIR to declare that\nthere is a single working tree associated with it. It fundamentally is\nincompatible with new-workdir, which is a hack to let more than one\nworking tree associated with a single GIT_DIR.\n\nI however do not think a simplistic \"unset core.worktree\" is a good\nsuggestion, though, as we do not know why the original repository has\nthat variable set pointing at somewhere. Blindly removing it will break\nthe use of the original repository. If somebody _really_ wants to use\nnew-workdir for whatever reason in such a setting, I would imagine that\ndoing something like this:\n\n - Create a new repository somewhere that is an identical copy of the\n original repository's GIT_DIR, except for core.worktree dropped;\n\n - Turn the working tree original repository pointed with core.worktree\n into a \"new-workdir\" off of that new repository; and\n\n - When you want more \"new-workdir\"s, create them off of that new copy.\n\nmay work. But honestly speaking, \"Do not use this hack---having more\nthan one working tree is fundamentally incompatible with it\", may be a\nmore sensible message.\n"},{"id":"189826","messageId":"CAHsq6J6MK4x7WZ=aox3hX11hFAng7Tp-XpR0ADs=UgUMwf20Ow@mail.gmail.com","threadId":"30297","inReplyTo":"xmqq397wzwwd.fsf@junio.mtv.corp.google.com","subject":"Re: contrib/workdir/git-new-workdir broken in 1.7.10 after introducing gitfiles","fromName":"Antonin Hildebrand","fromEmail":"antonin@hildebrand.cz","sentAt":"2012-04-22T03:56:16Z","receivedAt":"2012-04-22T03:56:16Z","isPatch":false,"sender":{"key":"antonin@hildebrand.cz","avatar":null},"body":"Quite frankly, the discussion got pretty technical for me and I don't follow it.\n\nI have just posted my current solution involving hard links instead\nnew-workdir script:\nhttp://stackoverflow.com/a/10265084/84283\n\nAlso it links this discussion as a warning that new-workdir may not be\nthe right solution.\n\nAnyways, thanks for your great job on git! Much appreciated.\n\nOn Sat, Apr 21, 2012 at 12:51 PM, Junio C Hamano wrote:\n> Jens Lehmann writes:\n>\n>> Opinions?\n>>\n>> ----8<-----\n>> Subject: [PATCH] git-new-workdir: Suggest unsetting the core.worktree setting\n>>\n>> Linking to a repository that has the core.worktree option set can only\n>> work when that core.worktree setting already points to the new-workdir.\n>> In all other cases strange things will happen, as new-workdir will be\n>> overridden by that setting.\n>\n> As you analyzed correctly, core.worktree lets a GIT_DIR to declare that\n> there is a single working tree associated with it. It fundamentally is\n> incompatible with new-workdir, which is a hack to let more than one\n> working tree associated with a single GIT_DIR.\n>\n> I however do not think a simplistic \"unset core.worktree\" is a good\n> suggestion, though, as we do not know why the original repository has\n> that variable set pointing at somewhere.  Blindly removing it will break\n> the use of the original repository.  If somebody _really_ wants to use\n> new-workdir for whatever reason in such a setting, I would imagine that\n> doing something like this:\n>\n>  - Create a new repository somewhere that is an identical copy of the\n>   original repository's GIT_DIR, except for core.worktree dropped;\n>\n>  - Turn the working tree original repository pointed with core.worktree\n>   into a \"new-workdir\" off of that new repository; and\n>\n>  - When you want more \"new-workdir\"s, create them off of that new copy.\n>\n> may work.  But honestly speaking, \"Do not use this hack---having more\n> than one working tree is fundamentally incompatible with it\", may be a\n> more sensible message.\n>\n>\n"},{"id":"189827","messageId":"xmqqy5poxtsc.fsf@junio.mtv.corp.google.com","threadId":"30297","inReplyTo":"xmqq397wzwwd.fsf@junio.mtv.corp.google.com","subject":"Re: contrib/workdir/git-new-workdir broken in 1.7.10 after introducing gitfiles","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-22T04:41:23Z","receivedAt":"2012-04-22T04:41:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> As you analyzed correctly, core.worktree lets a GIT_DIR to declare that\n> there is a single working tree associated with it. It fundamentally is\n> incompatible with new-workdir, which is a hack to let more than one\n> working tree associated with a single GIT_DIR.\n>\n> I however do not think a simplistic \"unset core.worktree\" is a good\n> suggestion, though, as we do not know why the original repository has\n> that variable set pointing at somewhere. Blindly removing it will break\n> the use of the original repository. If somebody _really_ wants to use\n> new-workdir for whatever reason in such a setting, I would imagine that\n> doing something like this:\n> ...\n> may work.\n\nI am too lazy to try it out myself, but a hack something along the line\nof the attached patch _might_ turn out to work well.\n\nAt least, it gives an incentive to people to update to more recent\nversions of git ;-) I dunno.\n\n-- >8 --\nSubject: new-workdir: use its own config file\n\nInstead of letting a new workdir share the same config, we simply\ninclude the original config and override core.worktree in it. This\nobviously changes the behaviour from the traditional workdir, by making\nany update to the config in a workdir private to that workdir and not\nreflected back to the original repository. Because a workdir is\nsupposed to be just a peek only window to check out a branch that is\ndifferent from the main working tree, and you are not expected to modify\nthe config file in any way (e.g. you do not create a new branch with\nremote configuration in a workdir), it may not be a huge issue.\n\nSigned-off-by: Junio C Hamano \n---\n contrib/workdir/git-new-workdir | 8 +++++++-\n 1 file changed, 7 insertions(+), 1 deletion(-)\n\ndiff --git a/contrib/workdir/git-new-workdir b/contrib/workdir/git-new-workdir\nindex 75e8b25..1d49258 100755\n--- a/contrib/workdir/git-new-workdir\n+++ b/contrib/workdir/git-new-workdir\n@@ -63,7 +63,7 @@ mkdir -p \"$new_workdir/.git\" || die \"unable to create \\\"$new_workdir\\\"!\"\n # create the links to the original repo. explicitly exclude index, HEAD and\n # logs/HEAD from the list since they are purely related to the current working\n # directory, and should not be shared.\n-for x in config refs logs/refs objects info hooks packed-refs remotes rr-cache svn\n+for x in refs logs/refs objects info hooks packed-refs remotes rr-cache svn\n do\n \tcase $x in\n \t*/*)\n@@ -77,6 +77,12 @@ done\n cd \"$new_workdir\"\n # copy the HEAD from the original repository as a default branch\n cp \"$git_dir/HEAD\" .git/HEAD\n+cat >\".git/config\" < Junio C Hamano writes:\n> \n>> As you analyzed correctly, core.worktree lets a GIT_DIR to declare that\n>> there is a single working tree associated with it. It fundamentally is\n>> incompatible with new-workdir, which is a hack to let more than one\n>> working tree associated with a single GIT_DIR.\n>>\n>> I however do not think a simplistic \"unset core.worktree\" is a good\n>> suggestion, though, as we do not know why the original repository has\n>> that variable set pointing at somewhere. Blindly removing it will break\n>> the use of the original repository. If somebody _really_ wants to use\n>> new-workdir for whatever reason in such a setting, I would imagine that\n>> doing something like this:\n>> ...\n>> may work.\n> \n> I am too lazy to try it out myself, but a hack something along the line\n> of the attached patch _might_ turn out to work well.\n\nA quick test worked just fine. Looks like you fixed git-new-workdir to\nbe usable with the new gitfile submodules ;-)\n"},{"id":"189842","messageId":"jn1kdh$6he$1@dough.gmane.org","threadId":"30297","inReplyTo":"xmqqy5poxtsc.fsf@junio.mtv.corp.google.com","subject":"Re: contrib/workdir/git-new-workdir broken in 1.7.10 after introducing gitfiles","fromName":"Mark Levedahl","fromEmail":"mlevedahl@gmail.com","sentAt":"2012-04-22T18:58:56Z","receivedAt":"2012-04-22T18:58:56Z","isPatch":false,"sender":{"key":"mdl123@verizon.net","avatar":"https://avatars.githubusercontent.com/u/5302462?v=4"},"body":"On 04/22/2012 12:41 AM, Junio C Hamano wrote:\n> Junio C Hamano writes:\n>\n>> As you analyzed correctly, core.worktree lets a GIT_DIR to declare that\n>> there is a single working tree associated with it. It fundamentally is\n>> incompatible with new-workdir, which is a hack to let more than one\n>> working tree associated with a single GIT_DIR.\n>>\n>> I however do not think a simplistic \"unset core.worktree\" is a good\n>> suggestion, though, as we do not know why the original repository has\n>> that variable set pointing at somewhere. Blindly removing it will break\n>> the use of the original repository. If somebody _really_ wants to use\n>> new-workdir for whatever reason in such a setting, I would imagine that\n>> doing something like this:\n>> ...\n>> may work.\n>\n> I am too lazy to try it out myself, but a hack something along the line\n> of the attached patch _might_ turn out to work well.\n>\n> At least, it gives an incentive to people to update to more recent\n> versions of git ;-) I dunno.\n>\n> -- >8 --\n> Subject: new-workdir: use its own config file\n>\n> Instead of letting a new workdir share the same config, we simply\n> include the original config and override core.worktree in it. This\n> obviously changes the behaviour from the traditional workdir, by making\n> any update to the config in a workdir private to that workdir and not\n> reflected back to the original repository. Because a workdir is\n> supposed to be just a peek only window to check out a branch that is\n> different from the main working tree, and you are not expected to modify\n> the config file in any way (e.g. you do not create a new branch with\n> remote configuration in a workdir), it may not be a huge issue.\n>\n\nThis change will break my use of new-workdir, which is maintaining \nmultiple checked out branches in separate directories, some with \nembedded modules, and being able to share changes and remote branches \nbetween them. These directories are time-consuming to set up, so the \nusually suggested approach of \"git-checkout $other_branch\" is not very \nuseful. All of the workdirs are set up off of a common set of bare repos \nkept elsewhere.\n\nThere are other ways to share between multiple independent repositories \non the same machine, but new-workdir is the simplest as there is no push \n/ pull / patch / am involved.\n\nI think the \"peek-only\" use case is better supported by clone, which on \na local machine does not copy the object store, and is of course \nwell-documented and in core-git. Perhaps a better patch is to just \nsuggest \"clone\" to the user who has core.worktree and/or submodules in use?\n\nMark\n"}]}