Git and submodules via HTTP [message #572432] |
Fri, 08 May 2009 08:49 |
Alex Blewitt Messages: 946 Registered: July 2009 |
Senior Member |
|
|
My understanding of a git submodule is that it is essentially a
git-repository-within-a-repository, with a pointer to a different git
repository's tree at a particular commit.
That would allow me (for example) to have a local checked out copy of (say)
http://example.com/parent.git
http://other.example.com/child.git
appear locally as parent/child in my file system. In order to do work on
child.git, any pushes would go to other.example.com; and when I've committed
my changes, I can commit parent.git (which would essentially update a pointer
from child.git/abcdef to child.git/123456 or whatever the tip pointed to).
So my question is, do these get served by nested HTTP requests, or must they
always be separate on the server? In other words, if I checked out 'parent',
would I just see parent.git/childsymlink coming down (and then the git client
would resolve symlink to otherhost/child.git automatically)?
I'm wondering whether I need to support recursive Git repositories in the HTTP
namespace, like whether I'd ever see http://example.com/parent.git/child.git
I'm also trying to find out how I'd parse the URL to identify a specific git
repo. For example, I could have a server hosting multiple git repositories
e.g.
http://example.com/public/product.git
http://example.com/private/other.git
And then either with the --export-all or similar, how I'd then find out which
part of the URL is the parent repo and which isn't.
Lastly, can I assume that the URL is always going to be of the form
http://example.com/.*/.*\.git/.* ? Or do we have to cater for the .git
extension being missing? I'm just wondering whether I can assume patterns in
the URL to initialise the Repo, or whether I'm going to have to hit the file
systems repeatedly looking fro (e.g.) public/.git, public.git/ etc. in order
to resolve the repo.
Alex
|
|
|
Powered by
FUDForum. Page generated in 0.01869 seconds