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

From: Jens Lehmann <jens.lehmann@web.de>
Date: May 30, 2013, 19:18 UTC
Message-ID: <51A7A5F9.2030107@web.de>
In-Reply-To: <7va9ndqqyf.fsf@alter.siamese.dyndns.org>

Am 30.05.2013 01:58, schrieb Junio C Hamano:

Show 12 quoted lines

> * 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;