Am 02.01.2011 16:55, schrieb Oliver Kullmann:
quoted text
> On Sun, Jan 02, 2011 at 12:30:15PM +0100, Jens Lehmann wrote:
>> Am 01.01.2011 21:39, schrieb Oliver Kullmann:
>>> On Fri, Dec 31, 2010 at 06:42:01PM -0500, Seth Robertson wrote:
>>> As far as I see that, this doesn't concern the problem how to I update
>>> one repository with submodules from another repository with "these" submodules
>>> (as the same paths)?
>>
>> I'm not sure I completely understand your use case, but submodules are
>> repositories of their own, so they don't get updated by just pulling
>> a superproject into another containing the same submodule. The submodule
>> changes have to be pushed to its own parent repository and can then be
>> fetched from there into another superproject's submodule.
> 
> I know that --- but if there wouldn't be any savings possible (in terms of using it),
> then submodules would be pointless, and so the question is *how* to use them.

No, they aren't pointless at all. But if you want to collaborate using
submodules they IMO work best if all your coworkers are able to access
the same submodule repos you are pushing to. Otherwise you'll have to
transport all submodule changes additionally to those of the superproject
(which might be more of a hassle than not using submodules in the first
place). Then you might be better off pulling the modules into your repo
using "git subtree" or "gitslave".

A possibility to put all submodule commits in the object directory of
the superproject has been discussed some time ago on this list [1] and
at the last GitTogether. That might be just what you need, but I am not
aware of any work done in that direction yet.

quoted text
> The good thing with Git is that there are no central repositories.
> That's exactly what I want to use, but again and again the automatic
> assumptions of "central repositories" are made, which should be actually alien to Git.

No, Git works perfectly fine with central repositories too (and that is
a feature :-). But I think I understand where your impression comes from.
Submodules don't work very well when you change URLs (that can result
in forcing your coworkers to do a "git submodule sync" in their repo
every time they switch to a commit with a changed URL). But while that
somehow works not being able to access a submodules repo doesn't work at
all. So the constraint for submodules is to have a repo which is visible
for the people you work with.

But submodules don't really force you into the centralized model, as you
can modify the .gitmodules file e.g. in a downstream fork and let it point
to your own forked version of the submodules repos where you can do your
own development independent of the submodules upstream.

quoted text
> Puuuh, I really really tried hard now to make my use-case clear :-|. Hopefully
> now the picture emerges.

Yep, thanks for sharing that!


[1] http://thread.gmane.org/gmane.comp.version-control.git/151473/
--
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