{"thread":{"id":"31270","subject":"Problems with new location of submodule's GIT_DIR","startedAt":"2012-08-17T15:28:19Z","lastAt":"2012-08-17T17:38:18Z","messageCount":3,"participants":["Daniel Milde","Jens Lehmann","Phil Hord"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"197184","messageId":"1345217299.7952.83.camel@athena.dnet","threadId":"31270","inReplyTo":null,"subject":"Problems with new location of submodule's GIT_DIR","fromName":"Daniel Milde","fromEmail":"daniel@milde.cz","sentAt":"2012-08-17T15:28:19Z","receivedAt":"2012-08-17T15:28:19Z","isPatch":false,"sender":{"key":"daniel@milde.cz","avatar":null},"body":"Hi all,\nI have encountered some difficulties with the new location of the\nmetainformation directory (GIT_DIR) of submodules.\n\nThe change of location happened in 1.7.8:\n\n * When populating a new submodule directory with \"git submodule init\",\n the $GIT_DIR metainformation directory for submodules is created\ninside\n $GIT_DIR/modules// directory of the superproject and referenced\n via the gitfile mechanism. This is to make it possible to switch\n between commits in the superproject that has and does not have the\n submodule in the tree without re-cloning.\n\nWhich problems it causes:\n\n1) You cannot move submodule easily (change the path to submodule). You\ncan either remove the submodule and then add it again to different path,\nor move the submodule directory and then edit path in its .git, change\npath in superproject's .git/modules dir and in .git/config. This is\nquite difficult in comparisson with previous behaviour when you can just\nmove the submodule and then stash changes.\n\n2) This change introduced many difficulties on Windows platform, because\nthere is limitation to path length and the way how paths are now\ncomposed leads to strange errors when project with submodules is in\nuser's dir. \n\n3) Submodules became dependent on superproject. This is quite bad if you\nare using submodules a lot (e.g. versioning the whole working space),\nbecause you cannot move or copy them out of the superproject now.\n\nI honestly don't know why this change was introduced because I have\nnever seen git removing any submodule while walking through the history.\nI have seen only the message saying that directory is not empty and so\ngit will not remove it. Or is there another reason why this change was\nadded to git?\n\nThanks\n\nCheers\nDaniel\n"},{"id":"197188","messageId":"502E73E4.9080601@web.de","threadId":"31270","inReplyTo":"1345217299.7952.83.camel@athena.dnet","subject":"Re: Problems with new location of submodule's GIT_DIR","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2012-08-17T16:40:04Z","receivedAt":"2012-08-17T16:40:04Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 17.08.2012 17:28, schrieb Daniel Milde:\n> Hi all,\n> I have encountered some difficulties with the new location of the\n> metainformation directory (GIT_DIR) of submodules.\n> \n> The change of location happened in 1.7.8:\n> \n> * When populating a new submodule directory with \"git submodule init\",\n> the $GIT_DIR metainformation directory for submodules is created\n> inside\n> $GIT_DIR/modules// directory of the superproject and referenced\n> via the gitfile mechanism. This is to make it possible to switch\n> between commits in the superproject that has and does not have the\n> submodule in the tree without re-cloning.\n> \n> Which problems it causes:\n> \n> 1) You cannot move submodule easily (change the path to submodule). You\n> can either remove the submodule and then add it again to different path,\n> or move the submodule directory and then edit path in its .git, change\n> path in superproject's .git/modules dir and in .git/config. This is\n> quite difficult in comparisson with previous behaviour when you can just\n> move the submodule and then stash changes.\n\nUnfortunately that is currently the case. Plans are to have something\nlike a \"git submodule mv\", which will do all the magic and make moving\nsubmodules easy again.\n\n> 2) This change introduced many difficulties on Windows platform, because\n> there is limitation to path length and the way how paths are now\n> composed leads to strange errors when project with submodules is in\n> user's dir. \n\nHmm, this sounds more like the problems we had with \"c:\" and \"/c\",\nwhich are fixed in current git. What version are you using?\n\n> 3) Submodules became dependent on superproject. This is quite bad if you\n> are using submodules a lot (e.g. versioning the whole working space),\n> because you cannot move or copy them out of the superproject now.\n\nOkay, that use case is new to me. What is the intention when you move a\nsubmodule out of the work tree? Couldn't you just as easily clone the\nupstream repo again at the new place?\n\n> I honestly don't know why this change was introduced because I have\n> never seen git removing any submodule while walking through the history.\n> I have seen only the message saying that directory is not empty and so\n> git will not remove it. Or is there another reason why this change was\n> added to git?\n\nBut that is just the same as when a submodules appears and you check\nout a commit before the submodule was added. It should be removed but\ncurrently isn't, which we can change in a future git version now the\ngit directory lives in a safe place. Other reasons are:\n\n*) Converting a directory tree into a submodules (or the other way\n round) is currently virtually impossible to handle. But that'll\n work just fine in the near future, which will make a lot of users\n happy.\n\n*) It is easy to accidentally throw away the submodules history and\n unpushed changes when removing it from the work tree (e.g. because\n you don't work on that part of the tree anymore), which should\n only contain tracked content and not repository data like it did.\n\nSo we did that change to make submodule handling easier and to be able\nto support valid use cases which we couldn't. Sorry for the hassle,\nbut we believe it is worth it in the long run.\n"},{"id":"197197","messageId":"CABURp0q84skieqmdd5qSBrdXFTOjNm5asQgVrB42UttrEOEpDw@mail.gmail.com","threadId":"31270","inReplyTo":"502E73E4.9080601@web.de","subject":"Re: Problems with new location of submodule's GIT_DIR","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2012-08-17T17:38:18Z","receivedAt":"2012-08-17T17:38:18Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Fri, Aug 17, 2012 at 12:40 PM, Jens Lehmann wrote:\n> Am 17.08.2012 17:28, schrieb Daniel Milde:\n>> Hi all,\n>> I have encountered some difficulties with the new location of the\n>> metainformation directory (GIT_DIR) of submodules.\n>>\n>> The change of location happened in 1.7.8:\n>>\n>> * When populating a new submodule directory with \"git submodule init\",\n>> the $GIT_DIR metainformation directory for submodules is created\n>> inside\n>> $GIT_DIR/modules// directory of the superproject and referenced\n>> via the gitfile mechanism. This is to make it possible to switch\n>> between commits in the superproject that has and does not have the\n>> submodule in the tree without re-cloning.\n>>\n>> Which problems it causes:\n\n>> 3) Submodules became dependent on superproject. This is quite bad if you\n>> are using submodules a lot (e.g. versioning the whole working space),\n>> because you cannot move or copy them out of the superproject now.\n>\n> Okay, that use case is new to me. What is the intention when you move a\n> submodule out of the work tree? Couldn't you just as easily clone the\n> upstream repo again at the new place?\n\nNot all git projects have upstreams. Maybe this is a local project only.\n\nIn any case, cloning the upstream anew does not preserve local history.\n\nMaybe the future 'git submodule mv' can be smart about moving a\nsubmodule to a new location outside of a superproject. Maybe it can\ndo so explicitly with the --export switch.\n\nPhil\n"}]}