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

From: Martin Waitz <tali@admingilde.org>
Date: Apr 11, 2007, 11:31 UTC
Message-ID: <20070411113150.GL21701@admingilde.org>
In-Reply-To: <200704111047.01271.andyparkins@gmail.com>

hoi :)

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

Show 11 quoted lines

> 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.

Show 5 quoted lines

> 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.

Show 13 quoted lines

> 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.

Show 5 quoted lines

> 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.

Show 7 quoted lines

> 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.

Show 5 quoted lines

> 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