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

[Martin Waitz <tali@admingilde.org>]

[-- Attachment #1: Type: text/plain, Size: 4417 bytes --]

hoi :)

On Wed, Apr 11, 2007 at 10:47:00AM +0100, Andy Parkins wrote:
> 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.

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]