From: Alex Riesen Date: Wed, 11 Apr 2007 08:49:18 GMT Subject: Re: [PATCH 6/6] Teach core object handling functions about gitlinks Message-ID: <81b0412b0704110149g50426a5fh149fe8607f9c163a@mail.gmail.com> In-Reply-To: <20070411083642.GH21701@admingilde.org> On 4/11/07, Martin Waitz wrote: > > >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. > 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?