Re: how to use two bare repositories?

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:

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

Oliver Kullmann <O.Kullmann@swansea.ac.uk> 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.

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

Can you please explain why?

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

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.