Re: Composing git repositories

Junio C Hamano wrote:

Ramkumar Ramachandra [off-list ref] writes:

quoted

Junio C Hamano wrote:

quoted

So you have to stash it somewhere.  We could have made it to move
them to $HOME/.safeplace or somewhere totally unrelated to the
superproject.  So in that sense, the repositories are *not* owned by
the superproject in any way.  However, you are working within the
context of the superproject on the submodule after all, and
somewhere under $GIT_DIR/ of the superorject is not too wrong a
place to use as such a safe place.

Thanks for the explanation.

What do you _exactly_ mean by that?  You understood why things are
arranged in that way, and no longer think that it is unnecessary,
ugly and unwieldy to stash the real copy of $GIT_DIR of submodules
away from their working trees and store them inside $GIT_DIR/modules
of the superproject?

In essence, git commands are built to act on pure worktrees.  It's
trivially Correct to pretend that an object store present in the
toplevel directory (as .git/) of the worktree doesn't exist, but it's
quite non-trivial to handle a .git directory anywhere else in the
worktree.  Since we built git ground-up to act on a single
repository's worktree, embedding one repository inside another is a
hack: as a "workaround", we simply relocate the object store of the
submodule repository.  Even then, working with one worktree embedded
inside another is something git never designed for: it explains why I
have to literally fight with git when using submodules (no offense
Jens; it's a very hard problem).

Representing submodules as commit objects in the tree is also a hack.
I'm sorry, but a submodule is not a commit object.  We need a fifth
object type if we want them to be first-class citizens.

Sorry, I'm deviating.  I learnt why you think the hack is necessary
and not "too wrong".  As I explained above, the entire design is
asymmetric and inelegant; I think we can do much better than this.