hoi :) On Wed, Apr 11, 2007 at 10:49:18AM +0200, Alex Riesen wrote: > On 4/11/07, Martin Waitz <tali@xxxxxxxxxxxxxx> 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:
signature.asc
Description: Digital signature