[thirdparty/git.git] / templates / hooks--pre-rebase

#!/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

################################################################

This sample hook safeguards topic branches that have been
published from being rewound.

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

The script, being an example, hardcodes the publish branch name
to be "next", but it is trivial to make it configurable via
$GIT_DIR/config mechanism.

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

Let'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"


A, 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.

We would want to allow C to be rebased, refuse A, and encourage
B to be deleted.

To compute (1):

	git-rev-list ^master ^topic next
	git-rev-list ^master        next

	if these match, topic has not merged in next at all.

To compute (2):

	git-rev-list master..topic

	if this is empty, it is fully merged to "master".
Commit	Line	Data
9a111c91 JH	1	#!/bin/sh
	2	#
	3	# Copyright (c) 2006 Junio C Hamano
	4	#
	5
	6	publish=next
	7	basebranch="$1"
	8	if test "$#" = 2
	9	then
	10	topic="refs/heads/$2"
	11	else
	12	topic=`git symbolic-ref HEAD`
	13	fi
	14
	15	case "$basebranch,$topic" in
	16	master,refs/heads/??/*)
	17	;;
	18	*)
	19	exit 0 ;# we do not interrupt others.
	20	;;
	21	esac
	22
	23	# Now we are dealing with a topic branch being rebased
	24	# on top of master. Is it OK to rebase it?
	25
	26	# Is topic fully merged to master?
	27	not_in_master=`git-rev-list --pretty=oneline ^master "$topic"`
	28	if test -z "$not_in_master"
	29	then
	30	echo >&2 "$topic is fully merged to master; better remove it."
	31	exit 1 ;# we could allow it, but there is no point.
	32	fi
	33
	34	# Is topic ever merged to next? If so you should not be rebasing it.
	35	only_next_1=`git-rev-list ^master "^$topic" ${publish} \| sort`
	36	only_next_2=`git-rev-list ^master ${publish} \| sort`
	37	if test "$only_next_1" = "$only_next_2"
	38	then
	39	not_in_topic=`git-rev-list "^$topic" master`
	40	if test -z "$not_in_topic"
	41	then
	42	echo >&2 "$topic is already up-to-date with master"
	43	exit 1 ;# we could allow it, but there is no point.
	44	else
	45	exit 0
	46	fi
	47	else
	48	not_in_next=`git-rev-list --pretty=oneline ^${publish} "$topic"`
	49	perl -e '
	50	my $topic = $ARGV[0];
	51	my $msg = "* $topic has commits already merged to public branch:\n";
	52	my (%not_in_next) = map {
	53	/^([0-9a-f]+) /;
	54	($1 => 1);
	55	} split(/\n/, $ARGV[1]);
	56	for my $elem (map {
	57	/^([0-9a-f]+) (.*)$/;
	58	[$1 => $2];
	59	} split(/\n/, $ARGV[2])) {
	60	if (!exists $not_in_next{$elem->[0]}) {
	61	if ($msg) {
	62	print STDERR $msg;
	63	undef $msg;
	64	}
65	print STDERR " $elem->[1]\n";
66	}
67	}
68	' "$topic" "$not_in_next" "$not_in_master"
69	exit 1
70	fi
71
72	exit 0
73
74	################################################################
75
76	This sample hook safeguards topic branches that have been
77	published from being rewound.
78
79	The workflow assumed here is:
80
81	* Once a topic branch forks from "master", "master" is never
82	merged into it again (either directly or indirectly).
83
84	* Once a topic branch is fully cooked and merged into "master",
85	it is deleted. If you need to build on top of it to correct
86	earlier mistakes, a new topic branch is created by forking at
87	the tip of the "master". This is not strictly necessary, but
88	it makes it easier to keep your history simple.
89
90	* Whenever you need to test or publish your changes to topic
91	branches, merge them into "next" branch.
92
93	The script, being an example, hardcodes the publish branch name
94	to be "next", but it is trivial to make it configurable via
95	$GIT_DIR/config mechanism.
96
97	With this workflow, you would want to know:
98
99	(1) ... if a topic branch has ever been merged to "next". Young
100	topic branches can have stupid mistakes you would rather
101	clean up before publishing, and things that have not been
102	merged into other branches can be easily rebased without
103	affecting other people. But once it is published, you would
104	not want to rewind it.
105
106	(2) ... if a topic branch has been fully merged to "master".
107	Then you can delete it. More importantly, you should not
108	build on top of it -- other people may already want to
109	change things related to the topic as patches against your
110	"master", so if you need further changes, it is better to
111	fork the topic (perhaps with the same name) afresh from the
112	tip of "master".
113
114	Let's look at this example:
115
116	o---o---o---o---o---o---o---o---o---o "next"
117	/ / / /
118	/ a---a---b A / /
119	/ / / /
120	/ / c---c---c---c B /
121	/ / / \ /
122	/ / / b---b C \ /
123	/ / / / \ /
124	---o---o---o---o---o---o---o---o---o---o---o "master"
125
126
127	A, B and C are topic branches.
128
129	* A has one fix since it was merged up to "next".
130
131	* B has finished. It has been fully merged up to "master" and "next",
132	and is ready to be deleted.
133
134	* C has not merged to "next" at all.
135
136	We would want to allow C to be rebased, refuse A, and encourage
137	B to be deleted.
138
139	To compute (1):
140
141	git-rev-list ^master ^topic next
142	git-rev-list ^master next
143
144	if these match, topic has not merged in next at all.
145
146	To compute (2):
147
148	git-rev-list master..topic
149
150	if this is empty, it is fully merged to "master".