Re: Question on git fetch to bare repo

From: Junio C Hamano <junkio@cox.net>
Date: Feb 13, 2007, 05:28 UTC
Message-ID: <7vejou39ud.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <17872.53830.887188.137662@lisa.zopyra.com>

Bill Lear <rael@zopyra.com> writes:

Show 9 quoted lines

> The problem I have with doing all of my fetching and merging in my
> private repo is this: I have an update hook in my public repo that I
> use to communicate my changes to my peers.  The problem is when I pull
> from a peer's repo into my private repo, make some of my changes, and
> then publish (push) my changes to the public repo, HIS changes are
> pushed as well, and the update script naturally picks up on these and
> broadcasts them.  My peer group ends up getting the same update
> message about his commits that they have already received.  Multiply
> this among 6 peers and it becomes a real headache.

I suspect that is because your "email when pushed" hook lists what commits are new on the branch. I do not use any "email when pushed" hook myself, so I do not know how yours is set up, but I suspect it is doing a moral equivalent of:

	#!/bin/sh
	name=<name of the branch the email will talk about>
	old=<commit before this push updates the branch tip>
        new=<commit this push is trying to update the branch tip with>

	git shortlog $old..$new |
        mailx -s "branch $name updated" recipients

That behaviour might be desirable when branches in the repositories are more or less independent, but in situations like yours where commit are cross pushed into each other's branches, you are not necessarily interested in the progress of each branch.

One solution would be to list only the new commits introduced by the push into the repository, regardless of the branch. You can replace the "git-shortlog $old..$new" with:

	git shortlog $new --not --all

to get that information, I think.