Re: ciabot scripts and merge flood prevention

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Joey Hess <joey@xxxxxxxxxxx>:
> 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: signature.asc
Description: Digital signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]