Re: tracking submodules out of main directory.

From: henri GEIST <henri.geist@flying-robots.com>
Date: Aug 5, 2011, 02:19 UTC
Message-ID: <1312510757.3261.1439.camel@Naugrim.eriador.com>
In-Reply-To: <20110804200529.GA35398@book.hvoigt.net>

Le jeudi 04 août 2011 à 22:05 +0200, Heiko Voigt a écrit :

Show 16 quoted lines

> Hi,
> 
> On Thu, Aug 04, 2011 at 12:29:22AM +0200, henri GEIST wrote:
> > Le mercredi 03 ao??t 2011 ?? 23:30 +0200, Jens Lehmann a ??crit :
> > > Let me make this clear: this is not about changing how submodules are
> > > committed in a superproject. It is not about having a loose collection of
> > > projects, they stay tied together in a defined state by the superproject.
> > > 
> > 
> > Yes but for me, from when I started this this topic, it was all about
> > having a loose collection of project with dependency references between
> > them. And get rid of the superproject.
> > It is my first and only goal.
> 
> In that case maybe what you want is your own completely independent
> implementation of a tool which manages a collection of submodules.

If I make a tool to managed a collection of submodules, it will became the superproject I want to get rid of. I do not want to have any concept of a collection. And that is why I do not want a superproject.

I have no exhaustive list of project/modules/submodules. Only some independent projects witch knows if they need some others.

Then I realy need the tool to be embedded in the repository.

> I doubt that tracking of submodules outside of the worktree will ever be
> accepted inside core git. Some dependency scheme which makes use of the
> current submodule implementation could be a feasible way but you can not
> get rid of the superproject.

I can not but have already done it.

> 
> Your approach introduces many problems which you were not able to
> present solutions for.

But it does not break anything. And generate no problem for me. There is only when you try to get one step more and try to use even more advanced things than I do on top of it. And those problem also apply to normal submodules.

Show 5 quoted lines

> So if you really want to work on this I suggest
> you try to implement your solution outside of core git first. If you can
> prove that you can solve all the immanent problems we can discuss
> integrating it into git again.
>

That is what I had proposed to do by making a file .gitdependencies
similar to .gitmodules and create shell script wrappers for :
  - git add
  - git status
  - git reset
  - git rm

the only thing is that with the previous patch I only had to touch "git add" every thing else was already ready to handle it.

Show 13 quoted lines

> > > Henri wanted it a bit upside down: any submodule could request a certain
> > > version of another submodule somewhere else in the repo. And he wanted to
> > > use gitlinks from one submodule to another for that, which I - hopefully -
> > > convinced him was no good idea.
> > > 
> > 
> > You just convince me that submodules are more than I need and to make a
> > lighter independent version of submodules which will never been followed
> > by git commands.
> 
> As described above this is probably the best way for you. Maybe you can
> prove that such a tool works but git's submodules implementation can
> currently not really assist you with your approach.

We will see.

	Henri