Am 27.03.2013 18:02, schrieb Ramkumar Ramachandra:
> 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.
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
> 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 .
> 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.
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