Re: Composing git repositories

Am 27.03.2013 18:02, schrieb Ramkumar Ramachandra:

Junio C Hamano wrote:

quoted

Ramkumar Ramachandra [off-list ref] writes:

quoted

Junio C Hamano wrote:

quoted

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/