Jens Lehmann <> writes:

> Am 02.06.2013 20:50, schrieb Junio C Hamano:
>> Jens Lehmann <> 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.


No need to hurry, but just to make sure this didn't disappear from
everybody's radar.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to