Junio C Hamano wrote:
> Ramkumar Ramachandra <artag...@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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html