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

[Jens Lehmann <Jens.Lehmann@web.de>]

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.

There are only two issues I'm aware of:

*) When the .gitmodules file is already modified but unchanged
   running rm or mv on a submodule will stage those changes too.

*) There is a harmless but unnecessary double invocation of strlen()
   in the function (fixed by the diff below).

I plan to fix the first issue in another patch which would also get
rid of the second issue, as exactly that code would have to be touched
anyways.

Does that make sense?

----------8<-----------------
diff --git a/submodule.c b/submodule.c
index edfc23c..4670af7 100644
--- a/submodule.c
+++ b/submodule.c
@@ -102,7 +102,7 @@ void stage_updated_gitmodules(void)
        struct cache_entry *ce;
        int namelen = strlen(".gitmodules");

-       pos = cache_name_pos(".gitmodules", strlen(".gitmodules"));
+       pos = cache_name_pos(".gitmodules", namelen);
        if (pos < 0) {
                warning(_("could not find .gitmodules in index"));
                return;