しらいしななこ <nanako3@xxxxxxxxxxxxxx> writes:
> Junio C Hamano <gitster@xxxxxxxxx> 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.
--
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
