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

[Martin Waitz <tali@admingilde.org>]

[-- Attachment #1: Type: text/plain, Size: 1444 bytes --]

hoi :)

On Wed, Apr 11, 2007 at 10:49:18AM +0200, Alex Riesen wrote:
> 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.
> 
> "Yes" what? It should _not_ correspond to HEAD?

Not neccessarily, yes.

Branches in the submodule make no sense unless they are independent
from 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.

> >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?

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

-- 
Martin Waitz

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]