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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 4, 2010, 11:46 UTC
Message-ID: <alpine.DEB.1.00.1001041157020.3695@intel-tinevez-2-302>
In-Reply-To: <61083.85.16.196.198.1262601871.squirrel@archive.darksea.de>

Hi,

On Mon, 4 Jan 2010, Heiko Voigt wrote:

Show 15 quoted lines

> Johannes wrote:
> > The real problem is that submodules in the current form are not very 
> > well designed.  For example, a submodule being at a different commit 
> > than in the superproject's index is not as fatal as the submodule 
> > having changes.
> >
> > So in the long run, IMHO a proper redesign of the submodules would not 
> > make only a little sense (it does not help, though, that those who 
> > implemented and furthered the current approach over other discussed 
> > approaches do not use submodules themselves -- not even now).
> 
> Do you mean the complete workflow (submodules are links to other git 
> repos) or the current implementation? Do you have links to other design 
> approaches/threads? Would be nice if we could take that into account for 
> any decision.

Unfortunately, I do not have any information about different approaches except the approach Subversion takes. While Subversion's externals are not perfect for all applications, for some, they are. So I consider this a serious shortcoming that Git does not support that workflow (and in fact, AFAIR Shawn's repo does not use submodules for that exact reason).

But I think that an important precondition to come up with a better design of the submodules is to have suffered the current implementation in real-world work using submodules. (Which reminds me very much of the autocrlf mess.)

Ciao, Dscho