how to use two bare repositories?

how to use two bare repositories?

[Oliver Kullmann]

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

Re: how to use two bare repositories?

[Junio C Hamano]

Oliver Kullmann <O.Kullmann@swansea.ac.uk> writes:

> 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 usual answer when you see a word "http" mentioned is...

	how are you arranging update-server-info to be run whenever B is
	updated?

Re: how to use two bare repositories?

[Jean-Luc Herren]

Oliver Kullmann wrote:
> 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 ???

Probably in your setup, B is tracking A as a remote and if you
fetch, only those remotes are updated, but not the local branches
in B.  If you then clone from B, you don't get B's remotes, you
get B's branches.  You probably want to do this:

path/to/B$ git remote rm origin
path/to/B$ git remote add --mirror origin path/to/A

Though, I wonder if it makes sense to have a 'git clone --bare'
set up the remote in mirror mode by default.  I'm unsure of what
use remotes are in a bare repo.

jlh

Re: how to use two bare repositories?

[Oliver Kullmann]

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
> 
> --

Re: how to use two bare repositories?

[Oliver Kullmann]

Sorry, by error I didn't post this message to the
list, but it might be interesting for somebody,
so here the copy.

----- Forwarded message from Oliver Kullmann <O.Kullmann@swansea.ac.uk> -----

X-Original-To: csoliver@cs-svr1.swan.ac.uk
Delivered-To: csoliver@cs-svr1.swan.ac.uk
Date: Sat, 12 Apr 2008 00:40:38 +0100
From: Oliver Kullmann <O.Kullmann@swansea.ac.uk>
To: Junio C Hamano <gitster@pobox.com>
Subject: Re: how to use two bare repositories?
In-Reply-To: <7v7if4ouan.fsf@gitster.siamese.dyndns.org>
User-Agent: Mutt/1.5.9i

On Fri, Apr 11, 2008 at 04:17:52PM -0700, Junio C Hamano wrote:
> Oliver Kullmann <O.Kullmann@swansea.ac.uk> writes:
> 
> > 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 usual answer when you see a word "http" mentioned is...
> 
> 	how are you arranging update-server-info to be run whenever B is
> 	updated?

Aha, I see: So first I fetch, and then I run update-server-info.
Just tried it out, and it worked. Thanks!

(By the way, since B is updated anyway only by my package-building
script, it's no problem to run update-server-info then (by the script).)

----- End forwarded message -----

Re: how to use two bare repositories?

[Junio C Hamano]

Oliver Kullmann <O.Kullmann@swansea.ac.uk> writes:

>> > 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 usual answer when you see a word "http" mentioned is...
>> 
>> 	how are you arranging update-server-info to be run whenever B is
>> 	updated?
>
> Aha, I see: So first I fetch, and then I run update-server-info.
> Just tried it out, and it worked. Thanks!

Typically, you would update a bare repository used for publishing by
pushing into it, and trigger update-server-info from the post-update hook.

But it is perfectly fine if you initiate a mirror-fetch from that
publishing repository (in your case, "B"), and the caller to "git fetch"
can run update-server-info after fetching.

And no, there is not a "post-fetch" hook, nor is there a need for one.

Re: how to use two bare repositories?

[しらいしななこ]

Junio C Hamano <gitster@pobox.com> writes:

> Typically, you would update a bare repository used for publishing by
> pushing into it, and trigger update-server-info from the post-update hook.
>
> But it is perfectly fine if you initiate a mirror-fetch from that
> publishing repository (in your case, "B"), and the caller to "git fetch"
> can run update-server-info after fetching.
>
> And no, there is not a "post-fetch" hook, nor is there a need for one.

Can you please explain why?

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

----------------------------------------------------------------------
Finally - A spam blocker that actually works.
http://www.bluebottle.com/tag/4

Re: how to use two bare repositories?

[Junio C Hamano]

しらいしななこ  <nanako3@bluebottle.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Typically, you would update a bare repository used for publishing by
>> pushing into it, and trigger update-server-info from the post-update hook.
>>
>> But it is perfectly fine if you initiate a mirror-fetch from that
>> publishing repository (in your case, "B"), and the caller to "git fetch"
>> can run update-server-info after fetching.
>>
>> And no, there is not a "post-fetch" hook, nor is there a need for one.
>
> Can you please explain why?

There are five valid reasons you might want to have a hook to a git
command/operation:

 (1) A hook that countermands the normal decision made by the underlying
     command.  Examples of this class are the update hook and the
     pre-commit hook.

 (2) A hook that operates on data generated after the command starts to
     run.  The ability to munge the commit log message by the commit-msg
     hook is an example.

 (3) A hook that operates on the remote end of the connection that you may
     not otherwise have access to, other than over the git protocol.  An
     example is the post-update hook that runs update-server-info.

 (4) A hook that runs under a lock that is acquired by the command for
     mutual exclusion.  Currently there is no example, but if we allowed
     the update hook to modify the commit that was pushed through
     send-pack => receive-pack pair, which was discussed on the list a
     while ago, it would be a good example of this.

 (5) A hook that is run differently depending on the outcome of the
     command.  The post-merge hook conditionally run by git-pull is an
     example of this (it is not even run if no merge takes place).
     Another example is the post-checkout hook that gets information that
     is otherwise harder to get (namely, if it was a branch checkout or
     file checkout -- you can figure it out by examining the command line
     but that already is part of the processing git-checkout does anyway,
     so no need to force duplicating that code in the userland).

You cannot do an equivalent operation from outside the git command for the
above classes of operations.  You need hooks for them.

On the other hand, if you want to always cause an action before or after
running a git opeation locally, you do not have to have a hook.  This is
true even if the action you would do after running a git operation depends
on what happened (class (5) above) if the result is easily observable
after the fact.

Of course there can be a very valid exception to the above policy.  If it
is common enough so that the policy means effectively everybody has to
reinvent the same wrapper.  But for this particular case I do not think
that is the case.