Re: What's cooking in git.git (May 2013, #09; Wed, 29)

From: Jens Lehmann <jens.lehmann@web.de>
Date: Jun 3, 2013, 21:27 UTC
Message-ID: <51AD0A25.5080101@web.de>
In-Reply-To: <7v61xwpct5.fsf@alter.siamese.dyndns.org>

Am 02.06.2013 20:50, schrieb Junio C Hamano:

Show 15 quoted lines

> Jens Lehmann <Jens.Lehmann@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.