Bill Lear <rael@xxxxxxxxxx> writes:
> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html