Re: GIT v1.5.1-rc1

From: Junio C Hamano <junkio@cox.net>
Date: Mar 21, 2007, 05:06 UTC
Message-ID: <7v648v5goy.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20070320025539.GA28922@spearce.org>

"Shawn O. Pearce" <spearce@spearce.org> writes:

Show 8 quoted lines

> I was hoping Andy or one of the other folks who have worked on
> that hook would pick up the ball and update the hook, but I
> think they are stuck on the fact that you cannot use:
>
> 	git log $new --not --all
>
> in the post-receive hook to see what commits are "new to this
> repository", as $new is already in --all.  ;-)

As you have the set of refs that were updated and their old and new commit object names, I do not think it is a problem at all. Instead of using --all, you can list the old commit object names for the refs involved in this round of the push and you enumerate the refs that are _not_ involved in this round of the push.

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:

	$ git checkout -b topic master
        $ git am series.mbox
	$ git checkout next
	$ git merge topic
        $ git push $URL next

The hook would report the commit resulting from patches in series.mbox after this push, which is fine.

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".

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.