ciabot scripts and merge flood prevention

ciabot scripts and merge flood prevention

[Joey Hess]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

There's a problem with the old ciabot scripts, and I think also the v3
versions, when two published branches are merged. In this case, ciabot
reports all the changes twice, once when they're first committed to the
first branch, and a second time when the first branch is merged into the
second. This can unleash a flood of redundant commit messages that wipes
out conversation in any poor irc channel that has CIA in it. I've
generated floods that lasted up to 15 minutes.

I document the problem and one solution here. There's also a link to 
the hook script Gnome is using, based on the same method.
http://kitenet.net/~joey/blog/entry/lazyweb:_git_cia_hooks/
Maybe this could be built into the ciabot scripts?


(BTW, in both scripts, the example of git-rev-list ... | tac
could perhaps more efficiently be written as git-rev-list --reverse ...)

-- 
see shy jo

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: ciabot scripts and merge flood prevention

[Eric Raymond]

[-- Attachment #1: Type: text/plain, Size: 2816 bytes --]

Joey Hess <joey@kitenet.net>:
> There's a problem with the old ciabot scripts, and I think also the v3
> versions, when two published branches are merged. In this case, ciabot
> reports all the changes twice, once when they're first committed to the
> first branch, and a second time when the first branch is merged into the
> second. This can unleash a flood of redundant commit messages that wipes
> out conversation in any poor irc channel that has CIA in it. I've
> generated floods that lasted up to 15 minutes.
> 
> I document the problem and one solution here. There's also a link to 
> the hook script Gnome is using, based on the same method.
> http://kitenet.net/~joey/blog/entry/lazyweb:_git_cia_hooks/
> Maybe this could be built into the ciabot scripts?

For the record, Joey suggests this:

while read oldrev newrev refname; do
    branchname=${refname#refs/heads/}
    [ "$branchname" = "master" ] && branchname=
    for merged in $(git rev-parse --symbolic-full-name --not --branches | egrep -v "^\^$refname$" | git rev-list --reverse --stdin $oldrev..$newrev); do
        ciabot_git.pl $merged $branchname
    done
done

with discussion that is short enough to reproduce here.

buxy writes:
>Dear Joey, we also had this problem for dpkg, that’s why I hacked the
>/usr/local/bin/git-commit-notice script that we’re using on Alioth to
>do something like this instead: [gives the above script]
>
>It will stop git rev-list each time that it encounters a commit that
>is available in any of the other branches present in the repository
>and thus when you merge a branch, you only see the merge commit in
>CIA.
>
>You should also note that the script is smarter as it calls CIA only
>for branch updates, not for tag creation (and other kinds of updates)
>where it only leads to strange errors IIRC.

I had noticed the strange errors on tag creation and was planning to
do something about it.  What I see happening is that the existing 
git rev-list call generates a list beginning with a commit ID consisting
of all zeros when the hook is called as the result of a tag push.

He also links to this: 

http://git.gnome.org/cgit/gitadmin-bin/tree/post-receive-notify-cia

> (BTW, in both scripts, the example of git-rev-list ... | tac
> could perhaps more efficiently be written as git-rev-list --reverse ...)

I had noticed this. I didn't change it because (a) I wasn't sure how far
back the --reverse argument went, and (b) I've been thinking about implmenting
some switches to change the calling interface so that the rev list 
expansion is dome internally. It needs to be smarter to banish the
tag-push problem.

I expect to be able to tackle this within the next four days.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]