Re: tracking submodules out of main directory.

[henri GEIST <henri.geist@flying-robots.com>]

Le mercredi 03 août 2011 à 23:45 +0200, Heiko Voigt a écrit :
> Hi,
> 
> On Wed, Aug 03, 2011 at 09:07:14PM +0200, Jens Lehmann wrote:
> > Am 03.08.2011 19:11, schrieb Junio C Hamano:
> > But the superproject is still the place to say: I know these versions of
> > all submodules work together, so I commit their gitlinks here. But this
> > scheme enables submodules to give hints to help the superproject's user.
> > 
> > > I also suspect that allowing each submodule to know and demand specific
> > > versions of other submodules will lead to inconsistencies. Which version
> > > of submodule C would you demand to have when submodule A wants version C0
> > > and submodule B wants version C1 of it?
> > 
> > Right, in the discussion so far it seemed like henri seems to be the only
> > user who is wanting an exact match, and he says he needs to see these
> > inconsistencies. But I think he can modify the "version xxx or newer" to
> > his needs without imposing these inconsistencies on users (like me) who
> > don't want to see them.
> 
> And I imagine if a submodule has such hints we could add a command say
> 
> 	git submodule resolve-dependencies
> 
> which could resolve such "I need a version newer than" hints given by a
> submodule to help the user to update a submodule in the superproject.
> 
> Disclaimer: I think we need to think about all the implications such a
> scheme introduces very carefully. The picture is still a bit blurry for
> me.
> 

As I see it if you want a command like
"git submodule resolve-dependencies"

  - the process need to decide if it will chose te lower version above
    all requierments or directly the head.
  - if one or more say I want exactly this version and it is not
    satisfied we need at least a warning.
  - We need to issue an error if all the required version can not be
    found in the same branch.

	Henri