hoi :)

On Wed, Apr 11, 2007 at 10:47:00AM +0100, Andy Parkins wrote:
quoted text
> On Wednesday 2007 April 11 09:06, Martin Waitz wrote:
>=20
> > The only thing I disagree with you is in using HEAD of the submodule:
>=20
> I know we've had this discussion before, but I'm going to bring it up aga=
in -=20
quoted text
> mainly because Linus's implementation exactly matches what I envisaged wh=
en=20
quoted text
> we originally spoke of this.  I think in your "Updating the branch which =
HEAD=20
quoted text
> points to is dangerous" section, the main thing you're not taking into=20
> account is that git can make detached checkouts.  Updating HEAD is not=20
> dangerous - updating refs is; and I don't think anyone is proposing that =
a=20
quoted text
> submodule ref should ever be updated by a supermodule.

Then we already agree on the most important part.
My argument is mostly against updating the ref which is behind HEAD, not
HEAD per se.  And I haven't thought about using detached HEADs until I
wrote the mail.

quoted text
> I think you're also too strongly focussed on the idea that the supermodul=
e=20
quoted text
> tracks submodule branches - it cannot branches are not part of "the"=20
> repository they point at "a" repository.  References are outside the=20
> repository pointing in, and hence the supermodule cannot refer to them at=
 its=20
quoted text
> core.

No, that may be an misunderstanding because my very first prototype
really did track branches.  In the meantime I changed my mind, my
current prototypes all track submodule commits directly.
But in doing so we create a branch of its own: remember, a branch in
git is just a moving reference into the history.  Such a reference
can be stored in .git/refs/heads or it can be stored in the index/tree of
the supermodule.  The difference is not really big.
So we do not track a branch, but we create a branch by tracking.

quoted text
> Now, if you check out a revision in the supermodule, that's going to look=
 up=20
quoted text
> the submodule revision stored in the DIRLINK tree entry which will recurs=
e=20
quoted text
> into the submodule and checkout that revision - almost certainly as a=20
> detached HEAD.  There are three possibilities then:
>  - The submodule revision is in the past and no submodule branch points a=
t it
quoted text
>  - The submodule revision is current and a submodule branch points at it
>  - The submodule revision is current and multiple submodule branches poin=
t at=20
quoted text
>    it
> The supermodule checkout will have to make a decision whether to update t=
he=20
quoted text
> submodule HEAD (in one case it's obvious: a revision in the past has to b=
e=20
quoted text
> detached HEAD as there is no suitable branch).  It's also possible that t=
he=20
quoted text
> single submodule branch case is easy - undetach HEAD; however I don't thi=
nk=20
quoted text
> that is universally correct.

I don't like to guess which branches to update.
I'd prefer to just unconditionally update one specific one.

quoted text
> I know you're very much in favour of making branches in the submodule=20
> correspond to branches in the supermodule, but I just don't see a way of=
=20
quoted text
> making it work - the supermodule cannot know about submodule branches,=20
> branches are not part of the repository, they just point at the repositor=
y. =20
quoted text
> My branches could be different from your branches.

That would not work, you are right.
Please see my above comment about tracking & branches.

quoted text
> The way submodules should be treated is that the whole submodule is analo=
gous=20
quoted text
> to a single repository-tracked file - that's essentially what a submodule=
 is=20
quoted text
> in the end but the content of the "file" is the submodule revision.

Wholeheartedly agreed.

quoted text
> Now, if you change branch in the submodule, the supermodule will see
> that as a change in the submodule (as it should).  If you changed
> back, it will be restored and the supermodule will again see it as
> unchanged.  If you commit on the submodule, the supermodule will see
> that as a change and you'll have to git-add the submodule and commit
> in the supermodule.  The submodule is on whatever branch it is on - at
> all times.

quoted text
> The only time I can see this causing difficulties is when you want to
> checkout the tip of a submodule branch - how is the supermodule to
> know when it is correct to change HEAD from being detached to being
> attached?  I suppose it's got to be config-based; and out-of-tree
> config at that.

Again, doing things conditionally here just adds to confusion.
Just have one dedicated branch and be done with it.

--=20
Martin Waitz