Am 02.06.2013 20:50, schrieb Junio C Hamano: > Jens Lehmann <Jens.Lehmann@xxxxxx> writes: > >> Am 30.05.2013 01:58, schrieb Junio C Hamano: >>> * jl/submodule-mv (2013-04-23) 5 commits >>> (merged to 'next' on 2013-04-23 at c04f574) >>> + submodule.c: duplicate real_path's return value >>> (merged to 'next' on 2013-04-19 at 45ae3c9) >>> + rm: delete .gitmodules entry of submodules removed from the work tree >>> + Teach mv to update the path entry in .gitmodules for moved submodules >>> + Teach mv to move submodules using a gitfile >>> + Teach mv to move submodules together with their work trees >>> >>> "git mv A B" when moving a submodule A does "the right thing", >>> inclusing relocating its working tree and adjusting the paths in >>> the .gitmodules file. <detailed discussion snipped> > So my gut feeling of the "fix" at this point in the evolution of the > program may be to error out with a message like "You have local > changes to .gitmodules; please stash it before moving or removing". Yeah, me too thinks that this is a sane short term solution (even though a "git submodule add" currently happily stages any unstaged modifications to the .gitmodules file too, that should not stop us from doing better for rm and mv ;-). And I also agree that in the long run the the git-config aware merge driver together with the 3-way merge of a modified .gitmodules file you described is the best solution. But I'd really like to complete the recursive update before tackling that, so for now I just added these two to the to-do list on my GitHub wiki page. I'll resubmit this series with the strlen() fix and the erroring out in case of unstaged modifications of the .gitmodules file as soon as I find some time. -- 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