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