"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes:
> 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.
-
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