Re: how to use two bare repositories?

From: Oliver Kullmann <o.kullmann@swansea.ac.uk>
Date: Apr 11, 2008, 23:23 UTC
Message-ID: <20080411232337.GO29940@cs-wsok.swansea.ac.uk>
In-Reply-To: <20080411222205.GN29940@cs-wsok.swansea.ac.uk>

Just adding a further question:

Apparently bare repositories are strange things, which perhaps are not really supported by git. Alright, then I use additionally a real repository C.

Now in the automated process of package generation, the user of my library gets always a clone of C, created by

git clone --no-hardlinks path-to-C

However having the origin C built into that clone is not really useful, since no user has access to C. The natural think to do would be to use instead

git clone --no-hardlinks --origin http:address-of-B path-to-C

but unfortunately

git complains that "http:address-of-B" is not suitable as an origin??

However "http:address-of-B" works for pull ?

If option "origin" doesn't work, how else is it possible to provide the package-clone with a sensible default value for the pull-operation (this can only be B here)?

Oliver

On Fri, Apr 11, 2008 at 11:22:05PM +0100, Oliver Kullmann wrote:

Show 29 quoted lines

> Hi,
> 
> I have the following problem:
> 
> We use a public repository, a bare repository A,
> used with push and pull via ssh.
> A is only to be used by the core developer group.
> 
> Now I want to create another public repository B,
> from which anonymous pull is possible via http.
> So B should be another bare repository.
> 
> The problem is now that it seems not to be possible
> to update B:
> 
> 1. pulling from A is not possible since B is bare;
> 2. fetching from A seems to work, checking the content of
>    B via gitk seems to indicate that B has been updated
>  --- however pulling from B doesn't work: The newly
>  fetched changes are not transported to a repository
>  which pulls from B ???
> 
> Hope somebody can shed light on this behaviour.
> 
> Thanks!
> 
> Oliver
> 
> --