Re: Composing git repositories

[Jens Lehmann <Jens.Lehmann@web.de>]

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