Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 5, 2010, 23:02 UTC
Message-ID: <alpine.DEB.1.00.1001052357500.4985@pacific.mpi-cbg.de>
In-Reply-To: <7vd41oz9mp.fsf@alter.siamese.dyndns.org>

Hi,

On Tue, 5 Jan 2010, Junio C Hamano wrote:

Show 16 quoted lines

> Jens Lehmann <Jens.Lehmann@web.de> writes:
> 
> >> I think "clone" has a chicken-and-egg problem.  If all of your 
> >> project ... what kind of participant you are.  It has to become 
> >> two-step process; either "clone" going interactive in the middle, or 
> >> you let the clone to happen and then "submodule init" to express that 
> >> information.
> >
> > Yes, we can leave it that way for now (first "clone" and then 
> > "submodule init <the submodules you need>"). We can migrate to the 
> > "group mapping" functionality later (which would then allow to force 
> > certain submodules to always be populated because they appear in every 
> > group).
> 
> Even with group mapping, you need to clone the superproject first, before
> seeing the mapping (which I would assume comes in the superproject).

That's just like saying "you only see the URL first, and you have to clone before you see what the project is about".

So in effect you are saying that things are bad. But you do not take the leap of imagination to say what we need to improve.

There are quite a number of settings which could benefit from git-clone -- finally -- learning to take more information than just the URL; autocrlf and submodules' "grouping" (which is a lousy name, by the way) being the most prominent examples (which the core Git developers very obviously do not use, otherwise the state of things would not be as sorry as it is).

Ciao, Dscho