Re: [RFC] Third round of support for cloning submodules

Martin Waitz, Mon, May 21, 2007 00:14:55 +0200:

quoted

 - Do we detach HEAD if the commit named by the superproject
   tree is not at the tip of the current branch of subproject?
   do we detach always even if the commit is at the tip?

We must not mess with random upstream branches of the submodule
just because they happen to reference the same tip.
That would be too confusing.

Strange. The very same reason I heard when I tried to explain why
branches are good. The people found them confusing, just like you now.
They preach Perforce, too.

Either use one special branch or detach.

Why not just detach always?

quoted

 - What would we do when the subproject working tree is not
   clean?

The same as with normal files:
error out if something is changed which conflicts with the requested
update.

This is called tree-level merge. Done by -m option (it does more than
that, yes, but this one too). While at it we can do file-level merge
as well, why not?

When we have a special managed-by-supermodule branch and the submodule
has another branch currently checked out we can entirely ignore this
issue.

Detached head isn't special enough?

quoted

 - How can a user decide which subproject to descend into and
   which subproject to ignore, and how does git remember the
   earlier decision made by the user without asking the same
   again, and how does a user express "now I want to also track
   that subproject I've ignored so far" and "now I am not
   interested in following that subproject anymore"?

I'd simply use explicit checkout of a submodule and removal of
the submodule to be a fine way to express the user's wish.

The directory of the submodule will be back by the next
git-checkout-index (in the current implementation).
Not the .git's, so yes it is a fine way to express user's wish: he
just initialize the subprojects he wants (by whatever way).