{"thread":{"id":"30903","subject":"git submodule vs GIT_WORK_TREE","startedAt":"2012-06-26T12:28:55Z","lastAt":"2012-07-02T08:22:11Z","messageCount":13,"participants":["Richard Hartmann","Junio C Hamano","Jens Lehmann"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"194271","messageId":"CAD77+gTVLsEOgWo+WDafzNOYOwSZQ2KkgBuibBXemVmGu_Fzgw@mail.gmail.com","threadId":"30903","inReplyTo":null,"subject":"git submodule vs GIT_WORK_TREE","fromName":"Richard Hartmann","fromEmail":"richih.mailinglist@gmail.com","sentAt":"2012-06-26T12:28:55Z","receivedAt":"2012-06-26T12:28:55Z","isPatch":false,"sender":{"key":"richih.mailinglist@gmail.com","avatar":"https://avatars.githubusercontent.com/u/754723?v=4"},"body":"Hi all,\n\nvcsh [1] has had an open bug[2] filed against it for some time now. I\ncame to the conclusion that I can not properly work around this within\nthe scope of vcsh so I am hoping for help on this list.\n\nAs you are most likely aware, `git submodule` allows you to access a\nseparate git repository in a sub-directory, e.g. $submodule, while\n$GIT_WORK_TREE forces git to operate in a specific directory. Combine\nthe two and the result is less than ideal. git is forced to operate in\n$GIT_WORK_TREE while it should operate on $GIT_WORK_TREE/$submodule,\ninstead.\n\nI think there are two options, here:\n\n* Make git append $submodule to $GIT_WORK_TREE, i.e. operate on\n$GIT_WORK_TREE/$submodule\n* Introduce $GIT_WORK_TREE_RELATIVE which allows submodule and\npotentially other commands to append to it\n\n\nDid I miss another option? Would anyone be willing to fix/implement this?\n\n\nThanks,\nRichard\n\n[1] https://github.com/RichiH/vcsh\n[2] https://github.com/RichiH/vcsh/issues/27\n"},{"id":"194290","messageId":"7vobo6cazk.fsf@alter.siamese.dyndns.org","threadId":"30903","inReplyTo":"CAD77+gTVLsEOgWo+WDafzNOYOwSZQ2KkgBuibBXemVmGu_Fzgw@mail.gmail.com","subject":"Re: git submodule vs GIT_WORK_TREE","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-26T16:07:59Z","receivedAt":"2012-06-26T16:07:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Richard Hartmann <richih.mailinglist@gmail.com> writes:\n\n> As you are most likely aware, `git submodule` allows you to access a\n> separate git repository in a sub-directory, e.g. $submodule, while\n> $GIT_WORK_TREE forces git to operate in a specific directory. Combine\n> the two and the result is less than ideal. git is forced to operate in\n> $GIT_WORK_TREE while it should operate on $GIT_WORK_TREE/$submodule,\n> instead.\n\nThe end user should not be asked to anything special.\n\nWhen the user exports GIT_WORK_TREE to tell git that the root of the\nworking tree the user wants to work on resides there (which is\nneeded when the user exports GIT_DIR to tell git that the user wants\nto work on that repository), that wish obviously applies only to\nthat repository.  If git decides to visit the working tree of a\ndifferent repository (e.g. a checkout of a submodule bound to the\nproject GIT_WORK_TREE points at), even if it is done in response to\nthe user action (e.g. like passing \"--recurse-submodules\" option),\nit should adjust GIT_WORK_TREE and GIT_DIR to be appropriate for\noperations in the submodule repository while doing so.  If the more\nrecent \"recursive\" behaviour forgets to do so, it simply is a bug.\n"},{"id":"194297","messageId":"4FE9FF0C.8050409@web.de","threadId":"30903","inReplyTo":"7vobo6cazk.fsf@alter.siamese.dyndns.org","subject":"Re: git submodule vs GIT_WORK_TREE","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2012-06-26T18:27:24Z","receivedAt":"2012-06-26T18:27:24Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 26.06.2012 18:07, schrieb Junio C Hamano:\n> Richard Hartmann <richih.mailinglist@gmail.com> writes:\n> \n>> As you are most likely aware, `git submodule` allows you to access a\n>> separate git repository in a sub-directory, e.g. $submodule, while\n>> $GIT_WORK_TREE forces git to operate in a specific directory. Combine\n>> the two and the result is less than ideal. git is forced to operate in\n>> $GIT_WORK_TREE while it should operate on $GIT_WORK_TREE/$submodule,\n>> instead.\n\nRichard, could you please tell us what git commands behave strange\nin what way and what your expectations were? A short test shows e.g.\n\"git submodule foreach\" operates on $(pwd)/submodule even though\nGIT_WORK_TREE is set while at the same time git status shows the same\nsubmodule as missing because it is looking for it in $GIT_WORK_TREE.\nIs that what you are talking about?\n\n> The end user should not be asked to anything special.\n> \n> When the user exports GIT_WORK_TREE to tell git that the root of the\n> working tree the user wants to work on resides there (which is\n> needed when the user exports GIT_DIR to tell git that the user wants\n> to work on that repository), that wish obviously applies only to\n> that repository.  If git decides to visit the working tree of a\n> different repository (e.g. a checkout of a submodule bound to the\n> project GIT_WORK_TREE points at), even if it is done in response to\n> the user action (e.g. like passing \"--recurse-submodules\" option),\n> it should adjust GIT_WORK_TREE and GIT_DIR to be appropriate for\n> operations in the submodule repository while doing so.  If the more\n> recent \"recursive\" behaviour forgets to do so, it simply is a bug.\n\nI'm not sure what you mean by \"appropriate for operations in the\nsubmodule repository\". Should the submodule work tree be searched\nfor under $GIT_WORK_TREE of the superproject or under $(pwd)?\n\nAs far as I can see all submodule code consistently clears all\nenvironment variables used by git before descending into a\nsubmodule (at least since February 2010 and 5ce9086dd). Maybe we\nshould change that so it sets the GIT_WORK_TREE environment to\n\"$GIT_WORK_TREE/submodule\" to be consistent?\n"},{"id":"194307","messageId":"7vobo5c0n0.fsf@alter.siamese.dyndns.org","threadId":"30903","inReplyTo":"4FE9FF0C.8050409@web.de","subject":"Re: git submodule vs GIT_WORK_TREE","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-26T19:51:31Z","receivedAt":"2012-06-26T19:51:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann <Jens.Lehmann@web.de> writes:\n\n> Am 26.06.2012 18:07, schrieb Junio C Hamano:\n> ...\n>> When the user exports GIT_WORK_TREE to tell git that the root of the\n>> working tree the user wants to work on resides there (which is\n>> needed when the user exports GIT_DIR to tell git that the user wants\n>> to work on that repository), that wish obviously applies only to\n>> that repository.  If git decides to visit the working tree of a\n>> different repository (e.g. a checkout of a submodule bound to the\n>> project GIT_WORK_TREE points at), even if it is done in response to\n>> the user action (e.g. like passing \"--recurse-submodules\" option),\n>> it should adjust GIT_WORK_TREE and GIT_DIR to be appropriate for\n>> operations in the submodule repository while doing so.  If the more\n>> recent \"recursive\" behaviour forgets to do so, it simply is a bug.\n>\n> I'm not sure what you mean by \"appropriate for operations in the\n> submodule repository\". Should the submodule work tree be searched\n> for under $GIT_WORK_TREE of the superproject or under $(pwd)?\n\nI think either\n\n (1) unset GIT_WORK_TREE/GIT_DIR if the process chdirs to\n     $GIT_WORK_TREE/submodule and $GIT_WORK_TREE/submodule/.git is\n     the controlling reopsitory of that submodule working tree, or\n\n (2) set GIT_WORK_TREE/GIT_DIR to point at the working tree and\n     repository of the submodule.\n\nwould be appropriate.\n\n> As far as I can see all submodule code consistently clears all\n> environment variables used by git before descending into a\n> submodule (at least since February 2010 and 5ce9086dd). Maybe we\n> should change that so it sets the GIT_WORK_TREE environment to\n> \"$GIT_WORK_TREE/submodule\" to be consistent?\n\nIf the user has to use GIT_WORK_TREE to mark the root level of the\nsuperproject working tree as such, it is very likely that the\ncontrolling repository of the superproject does not live in the\n$GIT_WORK_TREE/.git directory (in other words, $GIT_DIR points at\nsomewhere else).  Exporting GIT_WORK_TREE/submodule as the new value\nof GIT_WORK_TREE is sensible, but I do not see a reasonable way to\ndeduce the value of GIT_DIR for the submodule in such a case.  The\ncontrolling repository of the superproject is located somewhere\nrandom; there is no reason to assume the repository for the\nsubmodule is somewhere at fixed relation to it.\n\nDoes it mean the short answer to Richard's situation is \"Don't do\nit\"?  I am not sure, but it is starting to sound like it.\n"},{"id":"194323","messageId":"4FEA380D.8070001@web.de","threadId":"30903","inReplyTo":"7vobo5c0n0.fsf@alter.siamese.dyndns.org","subject":"Re: git submodule vs GIT_WORK_TREE","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2012-06-26T22:30:37Z","receivedAt":"2012-06-26T22:30:37Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 26.06.2012 21:51, schrieb Junio C Hamano:\n> Jens Lehmann <Jens.Lehmann@web.de> writes:\n> \n>> Am 26.06.2012 18:07, schrieb Junio C Hamano:\n>> ...\n>>> When the user exports GIT_WORK_TREE to tell git that the root of the\n>>> working tree the user wants to work on resides there (which is\n>>> needed when the user exports GIT_DIR to tell git that the user wants\n>>> to work on that repository), that wish obviously applies only to\n>>> that repository.  If git decides to visit the working tree of a\n>>> different repository (e.g. a checkout of a submodule bound to the\n>>> project GIT_WORK_TREE points at), even if it is done in response to\n>>> the user action (e.g. like passing \"--recurse-submodules\" option),\n>>> it should adjust GIT_WORK_TREE and GIT_DIR to be appropriate for\n>>> operations in the submodule repository while doing so.  If the more\n>>> recent \"recursive\" behaviour forgets to do so, it simply is a bug.\n>>\n>> I'm not sure what you mean by \"appropriate for operations in the\n>> submodule repository\". Should the submodule work tree be searched\n>> for under $GIT_WORK_TREE of the superproject or under $(pwd)?\n> \n> I think either\n> \n>  (1) unset GIT_WORK_TREE/GIT_DIR if the process chdirs to\n>      $GIT_WORK_TREE/submodule and $GIT_WORK_TREE/submodule/.git is\n>      the controlling reopsitory of that submodule working tree, or\n> \n>  (2) set GIT_WORK_TREE/GIT_DIR to point at the working tree and\n>      repository of the submodule.\n> \n> would be appropriate.\n\nAgreed.\n\n>> As far as I can see all submodule code consistently clears all\n>> environment variables used by git before descending into a\n>> submodule (at least since February 2010 and 5ce9086dd). Maybe we\n>> should change that so it sets the GIT_WORK_TREE environment to\n>> \"$GIT_WORK_TREE/submodule\" to be consistent?\n> \n> If the user has to use GIT_WORK_TREE to mark the root level of the\n> superproject working tree as such, it is very likely that the\n> controlling repository of the superproject does not live in the\n> $GIT_WORK_TREE/.git directory (in other words, $GIT_DIR points at\n> somewhere else).  Exporting GIT_WORK_TREE/submodule as the new value\n> of GIT_WORK_TREE is sensible, but I do not see a reasonable way to\n> deduce the value of GIT_DIR for the submodule in such a case.  The\n> controlling repository of the superproject is located somewhere\n> random; there is no reason to assume the repository for the\n> submodule is somewhere at fixed relation to it.\n> \n> Does it mean the short answer to Richard's situation is \"Don't do\n> it\"?  I am not sure, but it is starting to sound like it.\n\nNot at all, I was just trying to reach consensus on what the user\ncan reasonably expect when setting GIT_WORK_TREE in the presence of\nsubmodules. I will look into it to see how we can handle the cases\nwhere GIT_WORK_TREE and/or GIT_DIR are set.\n"},{"id":"194329","messageId":"7vzk7p8z38.fsf@alter.siamese.dyndns.org","threadId":"30903","inReplyTo":"4FEA380D.8070001@web.de","subject":"Re: git submodule vs GIT_WORK_TREE","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-26T22:53:15Z","receivedAt":"2012-06-26T22:53:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann <Jens.Lehmann@web.de> writes:\n\n> Am 26.06.2012 21:51, schrieb Junio C Hamano:\n> ...\n>> If the user has to use GIT_WORK_TREE to mark the root level of the\n>> superproject working tree as such, it is very likely that the\n>> controlling repository of the superproject does not live in the\n>> $GIT_WORK_TREE/.git directory (in other words, $GIT_DIR points at\n>> somewhere else).  Exporting GIT_WORK_TREE/submodule as the new value\n>> of GIT_WORK_TREE is sensible, but I do not see a reasonable way to\n>> deduce the value of GIT_DIR for the submodule in such a case.  The\n>> controlling repository of the superproject is located somewhere\n>> random; there is no reason to assume the repository for the\n>> submodule is somewhere at fixed relation to it.\n>> \n>> Does it mean the short answer to Richard's situation is \"Don't do\n>> it\"?  I am not sure, but it is starting to sound like it.\n>\n> Not at all, I was just trying to reach consensus on what the user\n> can reasonably expect when setting GIT_WORK_TREE in the presence of\n> submodules. I will look into it to see how we can handle the cases\n> where GIT_WORK_TREE and/or GIT_DIR are set.\n\nThanks, then I'll let you look into it.  I do not see how you could\ndetermine GIT_DIR for the submodule sensibly if the superproject's\nworking tree does not have its GIT_DIR as \".git\" at the top-level,\nthough.\n\nDeclaring that a checked out submodule _must_ have its controlling\nrepository as \".git\" at its root level, i.e. it should be accessible\nwithout using GIT_WORK_TREE/GIT_DIR at all just like a normal Git\nrepository is, would be a clean way to avoid the issue altogether\nand it still will allow the top-level superproject to be structured\nin a funny way to require GIT_WORK_TREE/GIT_DIR to access it, but I\nam not sure if that is too restrictive for people who for some\nunknown reason want to use these environment variables to create\nrepositories with a strange layout.\n"},{"id":"194431","messageId":"CAD77+gSyhR+4vdv3dEVSuEvyt7mT9ojT-F2BrwTL4FsXpNFeHA@mail.gmail.com","threadId":"30903","inReplyTo":"7vzk7p8z38.fsf@alter.siamese.dyndns.org","subject":"Re: git submodule vs GIT_WORK_TREE","fromName":"Richard Hartmann","fromEmail":"richih.mailinglist@gmail.com","sentAt":"2012-06-29T08:43:05Z","receivedAt":"2012-06-29T08:43:05Z","isPatch":false,"sender":{"key":"richih.mailinglist@gmail.com","avatar":"https://avatars.githubusercontent.com/u/754723?v=4"},"body":"Mangling the email I respond to out of order.\n\nOn Wed, Jun 27, 2012 at 12:53 AM, Junio C Hamano <gitster@pobox.com> wrote:\n\n> but I\n> am not sure if that is too restrictive for people who for some\n> unknown reason want to use these environment variables to create\n> repositories with a strange layout.\n\nThis is exactly the point. For vcsh[1] to work, I need to set it up like this:\n\n    richih@titanium  ~ % vcsh enter zsh\n    richih@titanium [zsh] [2] (git)-[master] ~ % echo $GIT_WORK_TREE\n    /home/richih\n    richih@titanium [zsh] [2] (git)-[master] ~ % echo $GIT_DIR\n    /home/richih/.config/vcsh/repo.d/zsh.git\n    richih@titanium [zsh] [2] (git)-[master] ~ %\n\n\n> Declaring that a checked out submodule _must_ have its controlling\n> repository as \".git\" at its root level, i.e. it should be accessible\n> without using GIT_WORK_TREE/GIT_DIR at all just like a normal Git\n> repository is, would be a clean way to avoid the issue altogether\n> and it still will allow the top-level superproject to be structured\n> in a funny way to require GIT_WORK_TREE/GIT_DIR to access it,\n\nI fear this would make vcsh unable to support submodules, ever.\n\n\n\nRichard\n\n[1] https://github.com/RichiH/vcsh\n"},{"id":"194433","messageId":"CAD77+gSKsU6T8P6dQeZofkh3jhrKbW3yVy1XqJ0J_K-bDt-H8A@mail.gmail.com","threadId":"30903","inReplyTo":"4FE9FF0C.8050409@web.de","subject":"Re: git submodule vs GIT_WORK_TREE","fromName":"Richard Hartmann","fromEmail":"richih.mailinglist@gmail.com","sentAt":"2012-06-29T09:10:31Z","receivedAt":"2012-06-29T09:10:31Z","isPatch":false,"sender":{"key":"richih.mailinglist@gmail.com","avatar":"https://avatars.githubusercontent.com/u/754723?v=4"},"body":"On Tue, Jun 26, 2012 at 8:27 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:\n\n> Richard, could you please tell us what git commands behave strange\n> in what way and what your expectations were?\n\nA real-life example can be found at:\n\n  https://gist.github.com/2992239\n\nlines 354 in the second and 353 in the third paste block.\n\n\n> As far as I can see all submodule code consistently clears all\n> environment variables used by git before descending into a\n> submodule (at least since February 2010 and 5ce9086dd). Maybe we\n> should change that so it sets the GIT_WORK_TREE environment to\n> \"$GIT_WORK_TREE/submodule\" to be consistent?\n\n>From how I understand the problem, this would solve it.\n\n-- \nRichard\n"},{"id":"194446","messageId":"7v8vf551iu.fsf@alter.siamese.dyndns.org","threadId":"30903","inReplyTo":"CAD77+gSyhR+4vdv3dEVSuEvyt7mT9ojT-F2BrwTL4FsXpNFeHA@mail.gmail.com","subject":"Re: git submodule vs GIT_WORK_TREE","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-29T20:03:21Z","receivedAt":"2012-06-29T20:03:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Richard Hartmann <richih.mailinglist@gmail.com> writes:\n\n> Mangling the email I respond to out of order.\n>\n> On Wed, Jun 27, 2012 at 12:53 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>\n>> but I\n>> am not sure if that is too restrictive for people who for some\n>> unknown reason want to use these environment variables to create\n>> repositories with a strange layout.\n>\n> This is exactly the point. For vcsh[1] to work, I need to set it up like this:\n>\n>     richih@titanium  ~ % vcsh enter zsh\n>     richih@titanium [zsh] [2] (git)-[master] ~ % echo $GIT_WORK_TREE\n>     /home/richih\n>     richih@titanium [zsh] [2] (git)-[master] ~ % echo $GIT_DIR\n>     /home/richih/.config/vcsh/repo.d/zsh.git\n>     richih@titanium [zsh] [2] (git)-[master] ~ %\n>\n>\n>> Declaring that a checked out submodule _must_ have its controlling\n>> repository as \".git\" at its root level, i.e. it should be accessible\n>> without using GIT_WORK_TREE/GIT_DIR at all just like a normal Git\n>> repository is, would be a clean way to avoid the issue altogether\n>> and it still will allow the top-level superproject to be structured\n>> in a funny way to require GIT_WORK_TREE/GIT_DIR to access it,\n>\n> I fear this would make vcsh unable to support submodules, ever.\n\nThen think of a workable alternative.  As it stands, I would have to\nsay that what vcsh tries to do with git is broken with respect to\nsubmodules.\n"},{"id":"194448","messageId":"7v4npt50kl.fsf@alter.siamese.dyndns.org","threadId":"30903","inReplyTo":"7v8vf551iu.fsf@alter.siamese.dyndns.org","subject":"Re: git submodule vs GIT_WORK_TREE","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-29T20:23:54Z","receivedAt":"2012-06-29T20:23:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n>>> Declaring that a checked out submodule _must_ have its controlling\n>>> repository as \".git\" at its root level, i.e. it should be accessible\n>>> without using GIT_WORK_TREE/GIT_DIR at all just like a normal Git\n>>> repository is, would be a clean way to avoid the issue altogether\n>>> and it still will allow the top-level superproject to be structured\n>>> in a funny way to require GIT_WORK_TREE/GIT_DIR to access it,\n>>\n>> I fear this would make vcsh unable to support submodules, ever.\n>\n> Then think of a workable alternative.  As it stands, I would have to\n> say that what vcsh tries to do with git is broken with respect to\n> submodules.\n\nJust to avoid misunderstanding.  I didn't mean \"vcsh and vcsh alone\nis broken while other solutions work just fine\".  What I meant was\n\"I agree with you that what vcsh tries to do is unworkable\".\n"},{"id":"194450","messageId":"7vvci93k6k.fsf@alter.siamese.dyndns.org","threadId":"30903","inReplyTo":"7v8vf551iu.fsf@alter.siamese.dyndns.org","subject":"Re: git submodule vs GIT_WORK_TREE","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-29T21:03:15Z","receivedAt":"2012-06-29T21:03:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n>>> Declaring that a checked out submodule _must_ have its controlling\n>>> repository as \".git\" at its root level, i.e. it should be accessible\n>>> without using GIT_WORK_TREE/GIT_DIR at all just like a normal Git\n>>> repository is, would be a clean way to avoid the issue altogether\n>>> and it still will allow the top-level superproject to be structured\n>>> in a funny way to require GIT_WORK_TREE/GIT_DIR to access it,\n\nLet's think aloud a bit with a simple example.  Imagine there is a\ndirectory hierarchy $HOME/a/b with a file $HOME/a/b/c in it.\n\n'$HOME/a' is a working tree of a Git managed project.  In a normal\nlayout, there is a $HOME/a/.git directory there that houses its Git\nrepository, and everything (recursively) outside $HOME/a/.git in the\ndirectory $HOME/a are working tree files of that repository.  You\ncan\n\n\tcd $HOME/a\n        git add b/c\n\nto add the file at path b/c, and commit the changes to it.\n\nYou can relocate $HOME/a/.git elsewhere, say $HOME/git/a.git, by\nexporting GIT_DIR=$HOME/git/a.git as long as you work at the top\nlevel of the working tree.  When GIT_DIR alone is set this way, you\nare giving no clue to Git where the top-level of the working tree is\n(remember, you relocated $HOME/a/.git away so there is no \".git\" in\nthe $HOME/a directory), so your $(cwd) will be always taken as the\ntop level of the working tree.\n\nIt is inconvenient if you want to work in $HOME/a/b.  So you can do\nthis:\n\n\tGIT_WORK_TREE=$HOME/a\n        export GIT_WORK_TREE\n        cd $HOME/a/b\n\tgit add c\n\nand everything works again.\n\nOr $HOME/a/b may be a separate project, and $HOME/a/.git repository\nbinds that as a submodule.  In a normal layout, a $HOME/a/b/.git\ndirectory is there that houses its Git repository.  'c' is a file\nthat appears at the top level of that working tree.  When you are at\nthe top-level of the superproject's working tree, you see b/ and Git\nknows it is a submodule, not a subdirectory of the superproject.  It\ncannot allow \"git add b/c\" to the superproject.\n\nAnd this will continue to work with GIT_DIR/GIT_WORK_TREE when you\nmove $HOME/a/.git elsewhere.\n\nWhat happens if you also moved $HOME/a/b/.git elsewhere?\n\nThis will still work when you want to work inside the submodule:\n\n\tGIT_WORK_TREE=$HOME/a/b\n        export GIT_WORK_TREE\n        cd $HOME/a/b\n\tgit add c\n\nto record the change to 'c' at the top-level of the working tree of\nthe submodule.\n\n*BUT*\n\nThere is no \".git\" in $HOME/a anywhere, so this breaks when you are\nin the superproject's working tree. There is no longer anything that\ntells Git that the $HOME/a/b path is a project boundary.\n\nYou could look at the index to notice b is known as a submodule, but\nthat is not a usable solution in general.  You could have done \"git\nrm --cached\" it, perhaps because you wanted to do something clever\nwith it, e.g. in preparation to move it, in which case we still\nwould want to treat it as the working tree of a separate Git\nrepository that is not yet (or no longer) connected to the working\ntree of the $HOME/a/ repository.\n\nBy the way, without any of the GIT_DIR/GIT_WORK_TREE hack, the\nfollowing sequence does not work correctly (it is a bug nobody cares\nabout), and we may want to correct it.\n\n\tmkdir -p /var/tmp/x/a/b\n        cd /var/tmp/x/a\n        git init ;# create a/.git\n        git init ;# create a/b/.git\n        >c && git add c ;# a/b/.git knows about c at the toplevel\n        cd .. ;# back at a\n        git add b/c\n\nEven though a/b/.git does not yet have a commit and 'b' has not been\nregistered as a submodule to its index, Git run in 'a' should notice\nthat b/c belongs to somebody else, and refuse to grab it.  It has\nenough cue (namely, the presense of a/b/.git and the directory being\na proper Git repository) to do so, but it currently does not use\nthat clue.\n"},{"id":"194454","messageId":"CAD77+gSu-RxtcyXqpF6+VanLh==_BJymTAnY2M_EiMz=b63F6g@mail.gmail.com","threadId":"30903","inReplyTo":"7vvci93k6k.fsf@alter.siamese.dyndns.org","subject":"Re: git submodule vs GIT_WORK_TREE","fromName":"Richard Hartmann","fromEmail":"richih.mailinglist@gmail.com","sentAt":"2012-07-01T10:34:33Z","receivedAt":"2012-07-01T10:34:33Z","isPatch":false,"sender":{"key":"richih.mailinglist@gmail.com","avatar":"https://avatars.githubusercontent.com/u/754723?v=4"},"body":"First of all, thanks for your detailed analysis; it cleared things up\nfor me quite a bit.\n\nI am not sure if this would work in all cases, but let's assume there\nis a new GIT_WORK_ROOT which will always point to the top level of a\ngiven repository (it would stay the same for submodules, as well).\n\nAs for storage of .git, GIT_DIR_ROOT would always point to a directory\nwhere git data is stored and GIT_DIR_NAME to the relative path within\nGIT_DIR_ROOT. Admittedly, this may be rather specific to vcsh, but I\ndon't see any other (reliable) option to support submodules.\n\n\nThanks,\nRichard\n"},{"id":"194464","messageId":"7v4npq374c.fsf@alter.siamese.dyndns.org","threadId":"30903","inReplyTo":"CAD77+gSu-RxtcyXqpF6+VanLh==_BJymTAnY2M_EiMz=b63F6g@mail.gmail.com","subject":"Re: git submodule vs GIT_WORK_TREE","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-07-02T08:22:11Z","receivedAt":"2012-07-02T08:22:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Richard Hartmann <richih.mailinglist@gmail.com> writes:\n\n> First of all, thanks for your detailed analysis; it cleared things up\n> for me quite a bit.\n>\n> I am not sure if this would work in all cases, but let's assume there\n> is a new GIT_WORK_ROOT which will always point to the top level of a\n> given repository (it would stay the same for submodules, as well).\n\nI do not think such a variable is necessary, and I do not think it\nhelps anything either.\n\nAs a submodule is an independent project and does not care if it is\nembedded inside another project (i.e. superproject), when you are\nworking in $HOME/a/b repository (going back to the example in the\nprevious message), whether using b/.git or GIT_WORK_TREE=$HOME/a/b\nas the clue to mark the root of the working tree of the project you\nare working in, there is no reason for Git to figure out that there\nis a containing superproject at $HOME/a, let alone that its\ncontrolling repository is at $HOME/a/.git (or somewhere else).\n\nThe problem is going the other way around.\n\nWhen you are working in the superproject, i.e. $HOME/a, there is a\nneed to know when you cross the project boundary at $HOME/a/b (and\nif you know $HOME/a/b is the project boundary, that automatically\nmeans $HOME/a/b is the root level of the working tree of the other\nproject, so Git with \"--recursive\" option _ought_ to be aboe to\nexport GIT_WORK_TREE one it goes into the working tree of the\nsubmodule without anything else).\n\nBut even if you can know where the project boundary is in the\nworking tree space, that does not automatically mean you will be\nable to know where the controlling repository for $HOME/a/b is, if\nyou moved it away from its natural location $HOME/a/b/.git to\nsomewhere else.  There needs to be a way to tell Git about that.\n\nAnd an obvious way to do so is to have $HOME/a/b/.git; it can be a\nreal repository, which would make things simple, but it does not\nhave to be.  It can be the \"gitfile:\" thing that points at somewhere\nelse.  In recent versions of git, submodule working trees have this\nas a \"gitfile:\" that points at $GIT_DIR/modules/$name of the\nsuperproject, so that the working tree can be removed when checking\nout an old version of superproject before such a submodule was added\nto the project without losing the controlling repository.\n\nSo I do not see a need for either WORK_ROOT or DIR_ROOT at all.\n\nThe superproject (e.g. $HOME/a) may have its controlling repository\nelsewhere (you are naming its location with $GIT_DIR when you name\nthe working tree of it with $GIT_WORK_TREE), and that controlling\nrepository can have modules/b directory that is the controlling\nrepository for the submodule whose working tree is at $HOME/a/b;\nthere is no need for anything else as long as there is enough clue\nfor the system to find out that $HOME/a/b is the project boundary.\n"}]}