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

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

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