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

From: Jens Lehmann <jens.lehmann@web.de>
Date: Jan 4, 2010, 17:04 UTC
Message-ID: <4B421F90.4090402@web.de>
In-Reply-To: <alpine.DEB.1.00.1001041038520.4985@pacific.mpi-cbg.de>

Am 04.01.2010 10:44, schrieb Johannes Schindelin:

> The real problem is that submodules in the current form are not very well 
> designed.

IMVHO using the tree sha1 for a submodule seems to be the 'natural' way to include another git repo. And it gives the reproducibility i expect from a scm. Or am i missing something?

It looks to me as most shortcomings come from the fact that most git commands tend to ignore submodules (and if they don't, like git gui and gitk do now, they e.g. only show certain aspects of their state).

Submodules are in heavy use in our company since last year. Virtually every patch i submitted for submodules came from that experience and scratched an itch i or one of my colleagues had (and the situation did already improve noticeably by the few things we changed). We are still convinced that using submodules was the right decision. But some work has still to be done to be able to use them easily and to get rid of some pitfalls.

> In ths short run, we can paper over the shortcomings of the submodules by 
> introducing a command line option "--include-submodules" to 
> update-refresh, diff-files and diff-index, though.

Maybe this is the way to go for now (and hopefully we can turn this option on by default later because we did the right thing ;-).