threads / discuss / 22498

Reacting to new commits in a poll-mirror

Subject: Reacting to new commits in a poll-mirror

## tl;dr

4 messages between Feb 2, 2010 and Feb 3, 2010.

replies: 3people: 2as markdown or json

martin f krafft· Feb 2, 2010, 22:02 UTC · lore
Folks,

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.

I can probably hack something up, e.g. store refs before a fetch and then iterate the refs between the stored refs and the HEAD, but this seems exceedingly hackish and I'd much rather have this information from git-fetch (like git-push calls post-receive).

Is this at all possible? Would it be possible? Where would this be done?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
the uncertainty principle:
  you can never be sure how many
  beers you had last night.
 
spamtraps: madduck.bogus@madduck.net
martin f krafft· Feb 3, 2010, 01:10 UTC · re: martin f krafft · lore

Re: Reacting to new commits in a poll-mirror

also sprach martin f krafft <madduck@madduck.net> [2010.02.03.1102 +1300]:
Show 5 quoted lines
> 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.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"life is what happens to you while you're busy making other plans."
                                                        -- john lennon
 
spamtraps: madduck.bogus@madduck.net
Junio C Hamano· Feb 3, 2010, 01:32 UTC · re: martin f krafft · lore

Re: Reacting to new commits in a poll-mirror

martin f krafft <madduck@madduck.net> writes:
Show 11 quoted lines
> also sprach martin f krafft <madduck@madduck.net> [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.

martin f krafft· Feb 3, 2010, 10:48 UTC · re: Junio C Hamano · lore

Re: Reacting to new commits in a poll-mirror

also sprach Junio C Hamano <gitster@pobox.com> [2010.02.03.1432 +1300]:
Show 11 quoted lines
> 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

This sounds pretty much what I had in mind, and you have convinced me that this is the right/better approach. Thanks for keeping those feet on the ground!

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
half a bee, philosophically, must ipso facto half not be.
but half the bee has got to be, vis-a-vis its entity. you see?
but can a bee be said to be or not to be an entire bee,
when half the bee is not a bee, due to some ancient injury?
                                                       -- monty python
 
spamtraps: madduck.bogus@madduck.net

← back to recent threads