I guess I rarely enough get into that situation that I can live with it though.

I think the –symbolic-full-name approach can work, though probably it should | egrep -v “^\^$refname$”

Anyway, maybe you can work-around this by using git rev-parse --symbolic-full-name --not --branches | grep -v $refname so that commits are not expanded to their sha1 and you will only grep out the right branch instead of all those that share the same sha1.

For example, if I have master, foo, and bar, and in both foo and bar, I do a ‘git merge -s theirs master’. Now, when I push foo and bar to the server, git-rev-parse will list the same sha1 3 times (with ^). But if all three are filtered out, all the stop points are gone.

Joey, I’m sorry for the dashes, but wordpress is trying to be smarter than it should… it’s replacing on the fly the double dashes and the quotes even if they are inside a <pre> or <code>.

git rev-parse --not --branches list the current SHA1 of all branches but preceded by “^”. We remove the currently updated branch from that list and we use that list as many stop points for git rev-list thanks to its --stdin option. Why whould git rev-parse return the same commit multiple times ?

Even with that fixed, I’m still seeing floods if I merge master into a branch and push.

Let’s see.. refname is refs/heads/branch, and ‘git rev-parse –not –branches’
lists its ref, multiple times (once for the branch, once for master) but the grep filters it out. So rev-list doesn’t stop. I think it should only grep out one instance of $(git rev-parse $refname).

So, currently untested:

for merged in $(git rev-parse –not –branches | perl -e ‘$r=shift; while () { if (!$seen && /$r/) { $seen=1 } else { print } }’ $(git rev-parse $refname) | git rev-list –reverse –stdin $oldrev..$newrev); do
/srv/git/ikiwiki.info/.git/hooks/ciabot_git.pl $merged $branchname
done