Am 27.03.2013 18:02, schrieb Ramkumar Ramachandra: > Junio C Hamano wrote: >> Ramkumar Ramachandra <artagnon@xxxxxxxxx> 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. Submodules work pretty well, no matter if you call them a "hack". And what you call a "workaround" allows us to move, remove and recreate submodules, which is one of *the* major inconveniences submodules currently have. > 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). Unless you acknowledge that submodules are a different repo, you'll always run into problems. I believe future enhancements will make this less tedious, but in the end they will stay separate repos (which is the whole point, you'd want to use a different approach - e.g. subtree - if you want to put stuff from different upstreams into a single repo without keeping the distinction where all that came from). > 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. What else than a commit object should that be??? Submodules are there to have a different upstream for a part of your work tree, and that means a commit in that repo is the only sane thing to record in the superproject. A lot of thought has been put into this, and it is definitely a good choice [1]. > 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. How? The "submodules suck, we should try a completely different approach" thingy comes up from time to time, but so far nobody could provide a viable alternative to what we currently do. And apart from that, let's not forget we identified some valuable improvements to submodules in this thread: *) Get rid of the "toplevel" requirement *) Add functionality to relocate the object store out of the work tree (either "git submodule to-gitfile" or something similar, maybe even as a separate script in contrib) *) Add an option to "git submodule add" (and/or maybe a config option) to relocate the object store immediately on adding an already present submodule All of those are topics I like to see materialize, and you are welcome to tackle them. [1]: http://article.gmane.org/gmane.comp.version-control.git/151857/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html