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

[Junio C Hamano <junkio@cox.net>]

Martin Waitz <tali@admingilde.org> writes:

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

Because 'submodule' is a project on its own, it can make
progress while the parent project is still using the stable
commit.  Think of this:

 - Your application uses product of another project as a
   library (e.g. you are doing video application and embedding
   ffmpeg).
   
 - Your 'master' commit records a commit in the library
   subproject.  Maybe library subproject declared stable 1.0 and
   that is what you used to integrate.

 - But being an independent project on its own, the library
   project can make progress, outside the context of this
   aggregated work (i.e. your application).  Next time you do:

	$ cd ffmpeg ; git fetch

   there may not be any branch that points at the exact "stable 1.0"
   commit.

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.