{"thread":{"id":"37544","subject":"git-new-workdir submodules interact poorly with core.worktree","startedAt":"2014-09-12T13:58:31Z","lastAt":"2014-09-13T11:25:31Z","messageCount":2,"participants":["Edward Z. Yang","Jens Lehmann"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"249303","messageId":"1410527113-sup-9003@sabre","threadId":"37544","inReplyTo":null,"subject":"git-new-workdir submodules interact poorly with core.worktree","fromName":"Edward Z. Yang","fromEmail":"ezyang@mit.edu","sentAt":"2014-09-12T13:58:31Z","receivedAt":"2014-09-12T13:58:31Z","isPatch":false,"sender":{"key":"ezyang@mit.edu","avatar":"https://gravatar.com/avatar/6aaa9d10a82c2cf3d676f1f9397c2ae05ee2534182eda446128c0fe7c04494ba?d=mp&s=160"},"body":"tl;dr You can't git-new-workdir checkouts which use core.worktree.  This\nis unfortunate because 'git submodule init' uses core.worktree by\ndefault, which means you can't recursively git-new-workdir without a\nhack.\n\nIn the beginning, the Developer created the remote Git repository and\nthe submodule.\n\n    mkdir -p remote/sub\n    (cd remote/sub && git init && touch a && git add a && git commit -m \"sub init\")\n    mkdir remote/top\n    cd remote/top\n    git init\n    git submodule add ../sub\n    git commit -m \"top init\"\n    cd ../..\n\nAnd the Developer said, \"Let there be a local clone and submodule\", and\nlo, there was a local clone and submodule:\n\n    git clone remote/top top\n    (cd top && git submodule init && git submodule update)\n\nthe Developer blessed the working copy, and said \"Be fruitful and\nincrease in number with git-new-workdir\":\n\n    git-new-workdir top worktop\n\nUnfortunately, this workdir didn't have the submodules initialized.\n\n    $ ls worktop/sub/\n    $\n\nNow, the Developer could have run:\n\n    $ (cd worktop && git submodule init && git submodule update)\n\nbut the resulting submodule would not have been shared with the original\nsubmodule, in the same way that git-new-workdir shared the Git metadata.\n\nThe Developer sought to create the submodule in its own likeness, but it\ndid not work:\n\n    $ rmdir worktop/sub && git-new-workdir top/sub worktop/sub\n    fatal: Could not chdir to '../../../sub': No such file or directory\n\nWhat was the Developer's fall from grace?  A glance at the config of\nthe original and new submodule shed light on the matter:\n\n    $ cat top/sub/.git\n    gitdir: ../.git/modules/sub\n    $ cat top/.git/modules/sub/config\n    [core]\n            repositoryformatversion = 0\n            filemode = true\n            bare = false\n            logallrefupdates = true\n            worktree = ../../../sub\n    $ cat worktop/sub/.git/config\n    [core]\n            repositoryformatversion = 0\n            filemode = true\n            bare = false\n            logallrefupdates = true\n            worktree = ../../../sub\n\ngit-new-workdir sought to reuse the config of top/sub/.git, but this\nconfiguration had core.worktree set.  For the original checkout,\nthis worked fine, since its location was .git/modules/sub; but for the\nnew workdir, this relative path was nonsense.\n\nI do not think there is really a way to make this work with\ncore.worktree.  Our saving grace, however, is there is a hack that can\nmake this work: we just need to use the\npre-501770e1bb5d132ae4f79aa96715f07f6b84e1f6 style of cloning\nsubmodules:\n\n    git clone remote/top oktop\n    git clone remote/sub oktop/sub\n    (cd oktop && git submodule init && git submodule update)\n\nNow recursive git-new-workdir will work.\n\nWhat's the upshot?  I propose two new features:\n\n1. A flag for git submodule update which reverts to the old behavior\nof making a seperate .git directory rather than collecting them together\nin the top-level .git/modules\n\n2. Teach git-new-workdir to complain if core.worktree is set in the\nsource config, and how to recursively copy submodules.\n\nWhat do peopl think?\n\nThanks,\nEdward\n"},{"id":"249347","messageId":"541429AB.8030202@web.de","threadId":"37544","inReplyTo":"1410527113-sup-9003@sabre","subject":"Re: git-new-workdir submodules interact poorly with core.worktree","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2014-09-13T11:25:31Z","receivedAt":"2014-09-13T11:25:31Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 12.09.2014 um 15:58 schrieb Edward Z. Yang:\n> tl;dr You can't git-new-workdir checkouts which use core.worktree.  This\n> is unfortunate because 'git submodule init' uses core.worktree by\n> default, which means you can't recursively git-new-workdir without a\n> hack.\n>\n> In the beginning, the Developer created the remote Git repository and\n> the submodule.\n>\n>      mkdir -p remote/sub\n>      (cd remote/sub && git init && touch a && git add a && git commit -m \"sub init\")\n>      mkdir remote/top\n>      cd remote/top\n>      git init\n>      git submodule add ../sub\n>      git commit -m \"top init\"\n>      cd ../..\n>\n> And the Developer said, \"Let there be a local clone and submodule\", and\n> lo, there was a local clone and submodule:\n>\n>      git clone remote/top top\n>      (cd top && git submodule init && git submodule update)\n>\n> the Developer blessed the working copy, and said \"Be fruitful and\n> increase in number with git-new-workdir\":\n>\n>      git-new-workdir top worktop\n>\n> Unfortunately, this workdir didn't have the submodules initialized.\n>\n>      $ ls worktop/sub/\n>      $\n>\n> Now, the Developer could have run:\n>\n>      $ (cd worktop && git submodule init && git submodule update)\n>\n> but the resulting submodule would not have been shared with the original\n> submodule, in the same way that git-new-workdir shared the Git metadata.\n>\n> The Developer sought to create the submodule in its own likeness, but it\n> did not work:\n>\n>      $ rmdir worktop/sub && git-new-workdir top/sub worktop/sub\n>      fatal: Could not chdir to '../../../sub': No such file or directory\n>\n> What was the Developer's fall from grace?  A glance at the config of\n> the original and new submodule shed light on the matter:\n>\n>      $ cat top/sub/.git\n>      gitdir: ../.git/modules/sub\n>      $ cat top/.git/modules/sub/config\n>      [core]\n>              repositoryformatversion = 0\n>              filemode = true\n>              bare = false\n>              logallrefupdates = true\n>              worktree = ../../../sub\n>      $ cat worktop/sub/.git/config\n>      [core]\n>              repositoryformatversion = 0\n>              filemode = true\n>              bare = false\n>              logallrefupdates = true\n>              worktree = ../../../sub\n>\n> git-new-workdir sought to reuse the config of top/sub/.git, but this\n> configuration had core.worktree set.  For the original checkout,\n> this worked fine, since its location was .git/modules/sub; but for the\n> new workdir, this relative path was nonsense.\n>\n> I do not think there is really a way to make this work with\n> core.worktree.  Our saving grace, however, is there is a hack that can\n> make this work: we just need to use the\n> pre-501770e1bb5d132ae4f79aa96715f07f6b84e1f6 style of cloning\n> submodules:\n>\n>      git clone remote/top oktop\n>      git clone remote/sub oktop/sub\n>      (cd oktop && git submodule init && git submodule update)\n>\n> Now recursive git-new-workdir will work.\n\nThanks for the report and a nice summary.\n\n> What's the upshot?  I propose two new features:\n>\n> 1. A flag for git submodule update which reverts to the old behavior\n> of making a seperate .git directory rather than collecting them together\n> in the top-level .git/modules\n\nThat would play bad with the upcoming recursive submodule update\n(which needs .git/modules to safely remove a submodule work tree),\nso I wouldn't want to do that step backwards.\n\n> 2. Teach git-new-workdir to complain if core.worktree is set in the\n> source config, and how to recursively copy submodules.\n\nI'd prefer pursuing this approach.\n"}]}