#!/bin/sh
#
# Copyright (c) 2006 Junio C Hamano
#

publish=next
basebranch="$1"
if test "$#" = 2
then
	topic="refs/heads/$2"
else
	topic=`git symbolic-ref HEAD`
fi

case "$basebranch,$topic" in
master,refs/heads/??/*)
	;;
*)
	exit 0 ;# we do not interrupt others.
	;;
esac

# Now we are dealing with a topic branch being rebased
# on top of master.  Is it OK to rebase it?

# Is topic fully merged to master?
not_in_master=`git rev-list --pretty=oneline ^master "$topic"`
if test -z "$not_in_master"
then
	echo >&2 "$topic is fully merged to master; better remove it."
	exit 1 ;# we could allow it, but there is no point.
fi

# Is topic ever merged to next?  If so you should not be rebasing it.
only_next_1=`git rev-list ^master "^$topic" ${publish} | sort`
only_next_2=`git rev-list ^master           ${publish} | sort`
if test "$only_next_1" = "$only_next_2"
then
	not_in_topic=`git rev-list "^$topic" master`
	if test -z "$not_in_topic"
	then
		echo >&2 "$topic is already up-to-date with master"
		exit 1 ;# we could allow it, but there is no point.
	else
		exit 0
	fi
else
	not_in_next=`git rev-list --pretty=oneline ^${publish} "$topic"`
	perl -e '
		my $topic = $ARGV[0];
		my $msg = "* $topic has commits already merged to public branch:\n";
		my (%not_in_next) = map {
			/^([0-9a-f]+) /;
			($1 => 1);
		} split(/\n/, $ARGV[1]);
		for my $elem (map {
				/^([0-9a-f]+) (.*)$/;
				[$1 => $2];
			} split(/\n/, $ARGV[2])) {
			if (!exists $not_in_next{$elem->[0]}) {
				if ($msg) {
					print STDERR $msg;
					undef $msg;
				}
				print STDERR " $elem->[1]\n";
			}
		}
	' "$topic" "$not_in_next" "$not_in_master"
	exit 1
fi

exit 0

##################################################################
#
# his sample hook safeguards topic branches that have been
# ublished from being rewound.
#
# he workflow assumed here is:
#
# * Once a topic branch forks from "master", "master" is never
#   merged into it again (either directly or indirectly).
#
# * Once a topic branch is fully cooked and merged into "master",
#   it is deleted.  If you need to build on top of it to correct
#   earlier mistakes, a new topic branch is created by forking at
#   the tip of the "master".  This is not strictly necessary, but
#   it makes it easier to keep your history simple.
#
# * Whenever you need to test or publish your changes to topic
#   branches, merge them into "next" branch.
#
# he script, being an example, hardcodes the publish branch name
# o be "next", but it is trivial to make it configurable via
# GIT_DIR/config mechanism.
#
# ith this workflow, you would want to know:
#
# 1) ... if a topic branch has ever been merged to "next".  Young
#    topic branches can have stupid mistakes you would rather
#    clean up before publishing, and things that have not been
#    merged into other branches can be easily rebased without
#    affecting other people.  But once it is published, you would
#    not want to rewind it.
#
# 2) ... if a topic branch has been fully merged to "master".
#    Then you can delete it.  More importantly, you should not
#    build on top of it -- other people may already want to
#    change things related to the topic as patches against your
#    "master", so if you need further changes, it is better to
#    fork the topic (perhaps with the same name) afresh from the
#    tip of "master".
#
# et's look at this example:
#
# 	   o---o---o---o---o---o---o---o---o---o "next"
# 	  /       /           /           /
# 	 /   a---a---b A     /           /
# 	/   /               /           /
#        /   /   c---c---c---c B         /
#       /   /   /             \         /
#      /   /   /   b---b C     \       /
#     /   /   /   /             \     /
#    ---o---o---o---o---o---o---o---o---o---o---o "master"
#
#
# , B and C are topic branches.
#
# * A has one fix since it was merged up to "next".
#
# * B has finished.  It has been fully merged up to "master" and "next",
#   and is ready to be deleted.
#
# * C has not merged to "next" at all.
#
# e would want to allow C to be rebased, refuse A, and encourage
#  to be deleted.
#
# o compute (1):
#
# git rev-list ^master ^topic next
# git rev-list ^master        next
#
# if these match, topic has not merged in next at all.
#
# o compute (2):
#
# git rev-list master..topic
#
# if this is empty, it is fully merged to "master".
