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

hoi :)

On Wed, Apr 11, 2007 at 10:47:00AM +0100, Andy Parkins wrote:

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

quoted

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.

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.

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.

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.

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 don't like to guess which branches to update.
I'd prefer to just unconditionally update one specific one.

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.

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

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.

Wholeheartedly agreed.

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.

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

-- 
Martin Waitz