Re: git-gui and gitk-git as submodules (Re: [RFC PATCH 0/2] Teach "git status" the "--ignore-submodules" option)

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

Am 28.06.2010 20:29, schrieb Marc Branchaud:
> On 10-06-26 07:45 AM, Jens Lehmann wrote:
> I applaud all the current submodule work -- thanks a ton!

Thanks for your feedback!


> I would like to ask submodule developers to please keep in mind scenarios
> where only a subset of the super-project's submodules are in use at one time.
>  In particular, please avoid forcing any blanket updates to all submodules.
> I think the features being discussed would be much more useful if they only
> applied to submodules that are already initialized and updated by the user,
> and that any unintialized submodules should be left alone.

Yes. I think we agreed some time ago that until the user can configure the
wanted behavior only populated submodules should be touched, so I don't
mention that explicitly anymore.


>> 1) Switching branches, merging, rebasing and resetting in the
>>    superproject must result in a checkout of the matching submodule
>>    work tree (right now you always have to issue a "git submodule
>>    update" afterwards to get the submodules in sync).
> 
> So, extending my request to this situation, I would say git should only
> update submodules that are already initialzied and updated.

Yes, see above.


>> 2) On "git clone" the submodules must be cloned and checked out too
>>    (currently you have to do a "git submodule update --init" after
>>    cloning the superproject).
> 
> Making clone do this automatically would be a show-stopper for us.  The
> current '--recursive' option is fine (though we never use it).
> 
> It would be interesting if the super-project could configure which submodules
> to automatically clone.

That's what I have in mind too. Maybe we could use the 'update' option of
.gitmodules to clone all those submodules where it is set. Then different
branches with different .gitmodules would behave differently.