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.
hoi :)
On Wed, Apr 11, 2007 at 02:15:36AM -0700, Junio C Hamano wrote:
Martin Waitz [off-list ref] writes:
quoted
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