Re: Composing git repositories
- From
Jens Lehmann <jens.lehmann@web.de>
- Date
- Mar 27, 2013, 23:02 UTC
- Message-ID
- <51537A7B.7050206@web.de>
- In-Reply-To
- <CALkWK0nARWAtC-D3UiNLccuaSwjR6meJb+Cu590N=8Ti8O7OMg@mail.gmail.com>
Am 27.03.2013 18:02, schrieb Ramkumar Ramachandra:
Show 27 quoted lines
> 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.
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/