Re: [PATCH 6/6] Teach core object handling functions about gitlinks

From: Alex Riesen <raa.lkml@gmail.com>
Date: Apr 11, 2007, 08:49 UTC
Message-ID: <81b0412b0704110149g50426a5fh149fe8607f9c163a@mail.gmail.com>
In-Reply-To: <20070411083642.GH21701@admingilde.org>

On 4/11/07, Martin Waitz <tali@admingilde.org> wrote:

Show 7 quoted lines

> > >Always read and write one dedicated branch (hardcoded "master" or
> > >configurable) when the supermodule wants to access a submodule.
> >
> > In this case it does not correspond to the working tree anymore.
> > HEAD is the "closest" to working tree of submodule.
>
> yes.

"Yes" what? It should _not_ correspond to HEAD?

> This has been discussed in length already.
> Please have a look at the archives.

I should. But at least a short summary of the reasons would be nice.

Show 5 quoted lines

> Your working tree now contains a complete git repository which has
> features which are not available for normal files.  Notable, you
> have the possibility to create branches in the submodule.
> If you insist in using HEAD you throw away those submodule capabilities.
>

In this (a very special, I believe) case, why not use git update-index --cacheinfo?