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

[Martin Waitz <tali@admingilde.org>]

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

hoi :)

On Wed, Apr 11, 2007 at 02:15:36AM -0700, Junio C Hamano wrote:
> Martin Waitz <tali@admingilde.org> writes:
> 
> > Your working tree now contains a complete git repository which has
> > features which are not available for normal files.  Notable, you
> > have the possibility to create branches in the submodule.
> > If you insist in using HEAD you throw away those submodule capabilities.
> 
> Why?  If you are working in the parent module (e.g integration)
> and notice breakage due to a bug in a submodule, it is very
> plausible that you would want to cd into the directory you have
> the submodule checked out, which has its own .git/ as its
> repository, and perform a fix-up there, with the goal of coming
> up with a commit usable by the parent project pointed at by the
> HEAD of the submodule repository.  And while working toward that
> goal, you will use branches, rebase, rewind or use StGIT there
> in that submodule repository.  It does not forbid you from using
> any of these things -- as long as you end up with a good commit
> at HEAD that the supermodule can use.

that's perfectly fine.
I only require one more thing: make sure that your commit is on
one dedicated branch (simply by merging your working/rebased/whatever
branch into the dedicated one) and not on some random one.

Again: for your above example this is not neccessary and using HEAD
would indeed be perfectly fine.

But you also have to update the submodule when you do a checkout in
the supermodule.  So what do you update?  Updating 'HEAD' is not
very concrete, please have a look at my initial mail to Linus.

What is stored in the supermodule?  It stores a reference to a specific
point in the history of the submodule.  As such I am convinced that
the right counterpart inside the submodule is a refs/heads/whatever,
and not the branch selector HEAD.
You can have other branches next to the one which is tracked by the
supermodule.  If you always update HEAD you don't have a clear
distinction between the branch which is tracked and other branches.

> Once you come up with a suitable commit sitting at HEAD of the
> submodule repository, you cd up to the parent module.  Top-level
> git-diff would notice that the commit recorded at the submodule
> path has been updated (because you now have a good commit at
> HEAD of the submodule repository, while earlier the one in your
> index was a dud).
> 
> So it is not clear to me what your argument about throwing away
> capabilities is.

If the supermodule just updates some random submodule branch I happen to
use at the time of a supermodule pull then submodule branches are
of much lower value.
Suddenly you have to make sure for yourself that the correct branch
gets updated.
For me, different branches should be independent and I want git to
always update the correct one.

-- 
Martin Waitz

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