Avery Pennarun wrote:
quoted text
> 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.

quoted text
> 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

quoted text
> 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?

quoted text
> 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.

quoted text
> 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

quoted text
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html