On Wednesday 2007 March 21 05:06, Junio C Hamano wrote: > But I do not think "new to this repository" is the right thing > to compute in the first place. In a heavily topic-oriented > development style, you may do something like this: Unfortunately, I think it's the only thing that can sensibly be done. Assume that we want every commit to appear on one, and only one email. It's got to be done by only showing the new commits. > However, after the topic cooks in 'next' and proves to be fine, > the next push would go like this: > > $ git checkout master > $ git merge topic > $ git push $URL master > > There is no new commit that appeared in the repository with this > push, and there will be no notification sent out, if you do "new > to this repository". Yes there is; the notification says that ref master was updated. It wouldn't show any new commits - which is exactly right. This to my mind is the same reason that fast-forward merges are better than all-merges-the-same. The truth is that there were no new commits, so the email generator should show no new commits; however there was a ref change so it should show that. That's exactly what the current hook does. The only fault in it, that I've yet to fix, is that it shows an empty log section; I eventually want the zero-new-commits case to be caught and a little description of why there are no new commits output instead. > The latter is, however, far more significant event than the > former, from the point of view of overall project history, both > for a casual user who tracks only the primary integration branch > and for a developer who is expected to fork his new work off of > the primary integration branch. Showing only new commits that > appeared in the repository is absolutely the wrong thing to do. I don't think so; either the merge generated a new commit, in which case that merge commit will be shown, or the merge didn't generate a new commit in which case the report of the branch change is all that is needed. Note: none of your examples describe a case where an email of some sort is not generated. Andy -- Dr Andy Parkins, M Eng (hons), MIET andyparkins@xxxxxxxxx - 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