martin f krafft <madduck@xxxxxxxxxxx> writes:
> also sprach martin f krafft <madduck@xxxxxxxxxxx> [2010.02.03.1102 +1300]:
>> I am trying to set up Patchwork-Git integration on host A for
>> a project whose Git repo is on host B. I thought I could use
>> a mirror (git clone --mirror) on A and regularly fetch from B, but
>> I cannot find a way (hook) to make Git on A react to new commits it
>> fetched from B.
>
> One way is to have a mirror on A, as well as a second repo: first,
> fetch to synchronise the mirror, the push to the second repo, where
> the post-receive hook will get executed. Works, but it's hackish.
> I'd much rather have hooks react right away to the fetch.
Sorry, but I don't understand the motivation.
You are the one with a desire to know "what new things I got by 'git
fetch' I am going to run right now".
And most importantly, that "right now" is under complete control of you.
Unlike post-receive hook that was invented as a way to be triggered by an
action done by somebody else, iow, an action you (the hook owner) do not
control at all, you do not need any hook around fetch to do what you are
trying to do. You know when you run fetch. You are the only one who
updates that repository A. Until you decide to fetch, nothing will change
in the repository A.
So I don't see what you find wrong about writing your script like:
#!/bin/sh
before_fetch=$(git for-each-ref --format='%(objectname)') &&
git fetch || exit
git rev-list --all --not $before_fetch |
while read rev
do
do your patchwork magic...
done
It seems (at least to me) to be exactly the way git plumbing layer was
designed to be used.
--
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