Re: Composing git repositories

[Ramkumar Ramachandra <artagnon@gmail.com>]

Junio C Hamano wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>> Junio C Hamano wrote:
>>> 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.