Am 26.02.2013 09:09, schrieb Chris Packham: > At $dayjob we were discussing a potential re-org of our super-projects > to introduce a bit of hierarchy to the submodules (at the moment it's > fairly flat). One downside of this is the potential loss of locally > committed work. There is also a cost in terms of additional fetching but > we think that will be OK (fetches from local servers with smallish repos). Local commits will be preserved iff the submodules use gitfiles, also extra fetches won't happen in that case. This holds true as long as you only change the path and not the name of the submodules in .gitmodules (Which I'd strongly advise to do and is just what my upcoming "git mv" patch will be doing, my plan is to post that as RFC rather soon). > I was just wondering where things were at with git detecting submodule > moving/renaming? Will our developers be able to keep any local commits > when they happen to pull in the super-project commit that moves a commit. Current Git detects that, but won't move the submodules work tree. Instead you'll have the old work tree of a moved submodule still lying around and need to call "git submodule update" to create the submodule's work tree in the new location. Also switching back to a commit where the submodule is still in the old location won't work at first because of the now outdated core.worktree setting in the Git repo of the submodule, still pointing to the new location. You'd have to delete the old submodule work tree and use "git submodule update" to recreate it again with proper settings. That'll somehow work while at the same time is not terribly user friendly (but don't even think about replacing an existing directory with tracked files with a submodule or vice versa with current Git!). The solution for all that is my recursive submodule update series, and finishing that it is next on my todo list after "git mv <submodule>". Also Heiko's recently posted "fetch moved submodules on-demand" series is necessary for that (and the work he does about parsing a config file from a blob is essential to create a submodule which doesn't have the correct path in the .gitmodules file of the current work tree, this is the major thing that doesn't work as expected in my current code). > I think some people with older clones will suffer without the newer > .git/modules layout but those can be manually fixed prior to the re-org. Or maybe someone could step up to add a "to-gitfile" command to "git submodule" which converts older submodules ;-) I'll be happy to help and review such a patch but will concentrate on materializing recursive submodule update for the next time. > FYI our current stock workstation install uses git version 1.7.9.5 but > I'm recommending we update to 1.8.x before this re-org to pick up some > of the recent submodule improvements. I think the stuff you need to make this transition painless (unless you are ok with a flag day or the manual steps described above to make that work) will not hit master that soon. While recursive update is working for me (except for creating a submodule not in the current .gitmodules) it still needs the config options and a ton of tests. My plan is to bring recursive submodule update into a shape others can test and comment on before the Git Merge in May, let's see how that plan works out. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html