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

[Martin Waitz <tali@admingilde.org>]

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

hoi :)

On Wed, Apr 11, 2007 at 01:01:17PM -0700, Junio C Hamano wrote:
> When you do a "checkout -f --recurse-into-subprojects" from the
> toplevel, I suspect that you would need to detach HEAD in the
> subproject repository grafted in your application tree to move
> it to the exact commit the toplevel project (i.e. your
> application) wants, and match the working tree to that commit.
> The toplevel simply should _not_ have to care what branch that
> commit comes from.

yes.

But why does everybody want to detach the submodule HEAD, instead
of creating one 'special' branch which holds the commit which is
used by the supermodule?

If you then want to switch to another submodule branch you loose
the reference that comes from the supermodule.

I want to create the extra branch exactly _because_ there is
independent work going on in the submodule (or the project it is
based on).  As you can switch between detached HEAD and an
independent branch you can also switch between the 'supermodule branch'
and independent branches -- only that you can easily switch back
if you have an branch of your own.

BTW: I also think that your --recurse-into-subprojects should
be implied.
If you check out one index entry, you should be able to read it
back afterwards.  That is a nice property everyone expects from
normal files and we should try to keep that for submodules.
When checkout_entry wants to touch a submodule we can simply rewrite
the 'supermodule branch' in the submodule.  If HEAD happens to point
to it we also read-tree the submodule.
This is easy to understand and implement and I have some good experience
with this model.

-- 
Martin Waitz

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