Re: Re: [PATCH v2 3/4] use new config API for worktree configurations of submodules

[Heiko Voigt <hvoigt@hvoigt.net>]

On Tue, Jul 08, 2014 at 01:14:20PM -0700, Junio C Hamano wrote:
> Heiko Voigt <hvoigt@hvoigt.net> writes:
> 
> > diff --git a/builtin/checkout.c b/builtin/checkout.c
> > index 07cf555..03ea20d 100644
> > --- a/builtin/checkout.c
> > +++ b/builtin/checkout.c
> > @@ -18,6 +18,7 @@
> >  #include "xdiff-interface.h"
> >  #include "ll-merge.h"
> >  #include "resolve-undo.h"
> > +#include "submodule-config.h"
> >  #include "submodule.h"
> >  #include "argv-array.h"
> >  
> 
> Hmph.  What is this change about?  
> 
> Nobody in checkout.c needs anything new, yet we add a new include?

This is because I moved the parse_submodule_config_option() function
into the submodule-config.c module. This was necessary so all parsed
submodule values are stored in the cache with the null_sha1. We use
static functions from this module to do this and thats thats the reason
for the move. 

> > diff --git a/diff.c b/diff.c
> > index f72769a..f692a3c 100644
> > --- a/diff.c
> > +++ b/diff.c
> > @@ -13,6 +13,7 @@
> >  #include "utf8.h"
> >  #include "userdiff.h"
> >  #include "sigchain.h"
> > +#include "submodule-config.h"
> >  #include "submodule.h"
> >  #include "ll-merge.h"
> >  #include "string-list.h"
> 
> Likewise.

Same as above.

> > It is somewhat unclear to me what real change that improves the life
> of end-users this series brings to us.   The "test-submodule-config"
> test program obviously is new but that does not really count until
> we see real uses.

Do you mean the API improvements? I split this series off from my
recursive fetch series since this infrastructure is also needed by Jens
recursive checkout series.

I am currently working on finishing the recursive fetch series here[1].
So until now we do not have any improvements for the end-user but only
in the API for the developer. With my series it is possible to easily
lookup what configuration for which submodule is in which revision. That
makes is possible to also implement the recursive fetch logic for
renamed submodules[2]. We are also able to decide whether (and from
where) a new submodules repository can possibly be cloned during
recursive fetch.

A clone on recursive fetch for new submodule makes sure we have
everything available, so a recursive checkout later can work without the
need for an extra fetch.

Does that make the improvements in my series clear for you? I would wait
until my recursive fetch series is ready so we have real uses. Since
there are others (namely Jens or submodule support for 'git archive')
that need it I think it makes sense to review and merge this separately
into master so they have a stable API to code against.

Cheers Heiko

[1] https://github.com/hvoigt/git/commits/hv/fetch-submodules-recursive
[2] https://github.com/hvoigt/git/commit/975c370856c3b8f96ab0c5a3ed754e3839f4de45