Re: git-submodule getting submodules from the parent repository

From: Sam Vilain <sam@vilain.net>
Date: Mar 29, 2008, 23:22 UTC
Message-ID: <47EECF1F.60908@vilain.net>
In-Reply-To: <32541b130803291535m317e84e6p321ebccd5dedaab3@mail.gmail.com>

Avery Pennarun wrote:

Show 8 quoted lines

> It would probably be possible to fix each of these problems
> individually, but it would be a whole series of different fixes.  I'd
> like to propose a rather different way of doing things that I think
> would solve most of these problems, and get some feedback:
> 
> What if *all* the objects for A, B, and C were always in the *same*
> repository?  Almost all the problems would go away.  Imagine if it
> worked like this:

Well, that would create a lot of unnecessary work when cloning. Partitioning by project is a natural way to divide the projects up. It's worth noting that the early implementations of submodules were based on this design, of keeping everything together.

However, what you are suggesting should IMHO be allowed to work. In particular, if the submodule path is ".", then I think there's a good case that they should come from within the same project. If it's a relative URL, it should initialize based on the remote URL that was used for the original fetch (or, rather, the remote URL for the current branch).

And, if it happens that after a checkout, that the commit of a submodule is already in the object directory (ie, there's another branch), then maybe that should automatically check out.

> 1. git-clone had a way to *not* clone every single object from every
> branch in the parent repository; only the ones you were interested in.

It could easily, if someone would allow clone to have a --track option like git remote does:

  git init
  git remote add -t branch -f URL

Show 5 quoted lines

> 2. You still check into C, then B, then A, but it doesn't actually
> matter if you put B and C on a branch first or not, because 'git push'
> will work properly, because it auto-pushes B and C revisions based on
> the fact that A refers to them (ie. implicit branches via the
> submodule mechanism).

This push failure thing is regrettable; however it's not clear which branch name the submodules should get. A given commit might exist on several branches, which one do you choose to name it?

> 4. You can 'git clone' a local copy of A, and B/C will be cloned
> automatically along with it.
> 6. git-pull should be modified to auto-download objects referred to by
> 'submodule' references in trees.

I think this could be a switch to git clone/pull, configurable to be the default action.

> 5. B and C, when git-submodule checks them out, should have their own
> .git directories, but use A as an 'alternatives' entry.

There is also a Google Summer of Code project for this - see http://git.or.cz/gitwiki/SoC2008Ideas#head-9215572f23513542a23d3555aa72775bc4b91038

> This would really help my workflow a lot.  Am I missing something?

Well, no, it's true that the current workflow has interface niggles; however it's important to understand why the current implementation is the way it is, and make sure that new designs build on top of the parts which are already designed well, where they can.

Sam