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
