Jens Lehmann <jens.lehm...@web.de> writes: > Am 02.06.2013 20:50, schrieb Junio C Hamano: >> Jens Lehmann <jens.lehm...@web.de> 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.
Ping? No need to hurry, but just to make sure this didn't disappear from everybody's radar. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
