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

From: Martin Waitz <tali@admingilde.org>
Date: Apr 11, 2007, 10:03 UTC
Message-ID: <20070411100328.GK21701@admingilde.org>
In-Reply-To: <7virc3p8zr.fsf@assigned-by-dhcp.cox.net>

hoi :)

On Wed, Apr 11, 2007 at 02:15:36AM -0700, Junio C Hamano wrote:

Show 18 quoted lines

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

Show 9 quoted lines

> 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