hoi :)

On Wed, Apr 11, 2007 at 10:49:18AM +0200, Alex Riesen wrote:
quoted text
> On 4/11/07, Martin Waitz <tali@admingilde.org> 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.
>=20
> "Yes" what? It should _not_ correspond to HEAD?

Not neccessarily, yes.

Branches in the submodule make no sense unless they are independent
=66rom supermodule branches.  And then changing to another branch in
the submodule automatically means that your current submodule working
directory should be independent to the supermodule.

git-status in the supermodule should of course warn when a submodule
is on a different branch, so that you don't accidently loose submodule
commits which did not get committed to the supermodule.

quoted text
> >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.
> >
>=20
> In this (a very special, I believe) case, why not use git update-index
> --cacheinfo?

I think misunderstood each other.
For me branching is not special case.

--=20
Martin Waitz