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

[Andy Parkins <andyparkins@gmail.com>]

On Wednesday 2007 April 11 09:06, Martin Waitz wrote:

> The only thing I disagree with you is in using HEAD of the submodule:

I know we've had this discussion before, but I'm going to bring it up again - 
mainly because Linus's implementation exactly matches what I envisaged when 
we originally spoke of this.  I think in your "Updating the branch which HEAD 
points to is dangerous" section, the main thing you're not taking into 
account is that git can make detached checkouts.  Updating HEAD is not 
dangerous - updating refs is; and I don't think anyone is proposing that a 
submodule ref should ever be updated by a supermodule.

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

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

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

It may be that some handy configuration settings and some clever porcelain 
could keep them in sync for your working repository - but it's never going to 
be the case that checking out "master" in the supermodule can be universally 
resolved to mean "checkout master in the submodule".

The way submodules should be treated is that the whole submodule is analogous 
to a single repository-tracked file - that's essentially what a submodule is 
in the end but the content of the "file" is the submodule revision.

There is one difference from ordinary files, a submodule has two "modified" 
states, not one:
 1. HEAD of submodule is different from DIRLINK revision
 2. Submodule is dirty

In state (1) the submodule has to have git-add run on it in the supermodule, 
just as you would with a modified file, to get it into the index (or not if 
you don't want to commit that change).  In state (2) it should be impossible 
to git-add, because the state of the submodule doesn't represent something 
that could be restored - there is nothing reasonable that could be written to 
the DIRLINK tree object.  This is certainly a porcelain issue, because it's 
only really a warning that "git-add" isn't doing what you think it's doing 
when the submodule is dirty.

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.

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.


Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com