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

Martin Waitz [off-list ref] 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.

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.