{"thread":{"id":"33015","subject":"state of the art with moving submodules","startedAt":"2013-02-26T08:09:54Z","lastAt":"2013-02-26T18:25:42Z","messageCount":2,"participants":["Chris Packham","Jens Lehmann"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"210318","messageId":"512C6DD2.4000208@gmail.com","threadId":"33015","inReplyTo":"bcaec55555fe91182f04d698b37f@google.com","subject":"state of the art with moving submodules","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2013-02-26T08:09:54Z","receivedAt":"2013-02-26T08:09:54Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"Hi Jens,\n\n(sorry for the dup. gmail insists on sending html)\n\nI know I saw a few threads regarding support for moving submodules but I\nlost track of the discussion.\n\nAt $dayjob we were discussing a potential re-org of our super-projects\nto introduce a bit of hierarchy to the submodules (at the moment it's\nfairly flat). One downside of this is the potential loss of locally\ncommitted work. There is also a cost in terms of additional fetching but\nwe think that will be OK (fetches from local servers with smallish repos).\n\nI was just wondering where things were at with git detecting submodule\nmoving/renaming? Will our developers be able to keep any local commits\nwhen they happen to pull in the super-project commit that moves a commit.\n\nI think some people with older clones will suffer without the newer\n.git/modules layout but those can be manually fixed prior to the re-org.\n\nFYI our current stock workstation install uses git version 1.7.9.5 but\nI'm recommending we update to 1.8.x before this re-org to pick up some\nof the recent submodule improvements.\n\nThanks\nChris\n"},{"id":"210343","messageId":"512CFE26.8060303@web.de","threadId":"33015","inReplyTo":"512C6DD2.4000208@gmail.com","subject":"Re: state of the art with moving submodules","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2013-02-26T18:25:42Z","receivedAt":"2013-02-26T18:25:42Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 26.02.2013 09:09, schrieb Chris Packham:\n> At $dayjob we were discussing a potential re-org of our super-projects\n> to introduce a bit of hierarchy to the submodules (at the moment it's\n> fairly flat). One downside of this is the potential loss of locally\n> committed work. There is also a cost in terms of additional fetching but\n> we think that will be OK (fetches from local servers with smallish repos).\n\nLocal commits will be preserved iff the submodules use gitfiles, also\nextra fetches won't happen in that case. This holds true as long as you\nonly change the path and not the name of the submodules in .gitmodules\n(Which I'd strongly advise to do and is just what my upcoming \"git mv\"\npatch will be doing, my plan is to post that as RFC rather soon).\n\n> I was just wondering where things were at with git detecting submodule\n> moving/renaming? Will our developers be able to keep any local commits\n> when they happen to pull in the super-project commit that moves a commit.\n\nCurrent Git detects that, but won't move the submodules work tree.\nInstead you'll have the old work tree of a moved submodule still lying\naround and need to call \"git submodule update\" to create the submodule's\nwork tree in the new location. Also switching back to a commit where the\nsubmodule is still in the old location won't work at first because of\nthe now outdated core.worktree setting in the Git repo of the submodule,\nstill pointing to the new location. You'd have to delete the old\nsubmodule work tree and use \"git submodule update\" to recreate it again\nwith proper settings. That'll somehow work while at the same time is not\nterribly user friendly (but don't even think about replacing an existing\ndirectory with tracked files with a submodule or vice versa with current\nGit!).\n\nThe solution for all that is my recursive submodule update series, and\nfinishing that it is next on my todo list after \"git mv <submodule>\".\nAlso Heiko's recently posted \"fetch moved submodules on-demand\" series\nis necessary for that (and the work he does about parsing a config file\nfrom a blob is essential to create a submodule which doesn't have the\ncorrect path in the .gitmodules file of the current work tree, this is\nthe major thing that doesn't work as expected in my current code).\n\n> I think some people with older clones will suffer without the newer\n> .git/modules layout but those can be manually fixed prior to the re-org.\n\nOr maybe someone could step up to add a \"to-gitfile\" command to \"git\nsubmodule\" which converts older submodules ;-)  I'll be happy to help\nand review such a patch but will concentrate on materializing recursive\nsubmodule update for the next time.\n\n> FYI our current stock workstation install uses git version 1.7.9.5 but\n> I'm recommending we update to 1.8.x before this re-org to pick up some\n> of the recent submodule improvements.\n\nI think the stuff you need to make this transition painless (unless you\nare ok with a flag day or the manual steps described above to make that\nwork) will not hit master that soon. While recursive update is working\nfor me (except for creating a submodule not in the current .gitmodules)\nit still needs the config options and a ton of tests. My plan is to\nbring recursive submodule update into a shape others can test and\ncomment on before the Git Merge in May, let's see how that plan works\nout.\n"}]}