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:
signature.asc
Description: Digital signature