From: Seth Robertson <in-gitvger@baka.org>
To: Oliver Kullmann <O.Kullmann@swansea.ac.uk>
Cc: git@vger.kernel.org
Subject: Re: how to have real (existing) submodules?
Date: Wed, 08 Dec 2010 17:25:09 -0500 [thread overview]
Message-ID: <201012082225.oB8MP939010091@no.baka.org> (raw)
In-Reply-To: <20101208205846.GW29789@cs-wsok.swansea.ac.uk>
In message <20101208205846.GW29789@cs-wsok.swansea.ac.uk>, Oliver Kullmann writ
es:
I thought that "git submodule" would solve the problem, but now I
realised that these submodules are not "real", but they only
contain a bit of meta-data (this should really be said directly in
the documentation).
So my hope, that I can have one super-repo, where I say, e.g.,
"git submodule foreach pull", get the full super-repo, copy it on
a memory stick, and then by pulling from that copy I get
everything into another super-repo, from which I distribute the
sub-repos, seems not so easily realisable with git?
gitslave may work for you better than git-submodules in this specific
use case. http://gitslave.sf.net
In your example, you would create an organizational super-project git
module which is primarily a container for the .gitslave file which
tells the system how to access the various git repos and their on-disk
path names.
Given your diverse repo locations, it sounds like you will not be
using the feature which allows the pathnames of the slave repos to be
relative based on the URL to the super-repo (though you could have a
mixture of relative and absolute URLs if that would help your
functionality).
You would then run `gits pull` to issue a `git pull` against every
slave repo, and likewise `gits push` or `gits push home` or whatever.
(remotes would best work if your gitslave system has relative URLs).
While the super-project cannot be bare, the slave-repos could be bare
if that would help your data transfer functionality.
If certain slave repos would not be accessible in all locations, there
are options to bypass the errors you will get attempting to contact
the unreachable repos.
If you have any questions, please let me know (here, private email, or
on #git).
-Seth Robertson
prev parent reply other threads:[~2010-12-08 22:25 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-08 20:58 how to have real (existing) submodules? Oliver Kullmann
2010-12-08 22:25 ` Seth Robertson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201012082225.oB8MP939010091@no.baka.org \
--to=in-gitvger@baka.org \
--cc=O.Kullmann@swansea.ac.uk \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox