1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/graster/hacklab-engraver/.git/hooks/pre-rebase.sample	Tue Aug 24 19:06:45 2010 -0400
     1.3 @@ -0,0 +1,169 @@
     1.4 +#!/bin/sh
     1.5 +#
     1.6 +# Copyright (c) 2006, 2008 Junio C Hamano
     1.7 +#
     1.8 +# The "pre-rebase" hook is run just before "git-rebase" starts doing
     1.9 +# its job, and can prevent the command from running by exiting with
    1.10 +# non-zero status.
    1.11 +#
    1.12 +# The hook is called with the following parameters:
    1.13 +#
    1.14 +# $1 -- the upstream the series was forked from.
    1.15 +# $2 -- the branch being rebased (or empty when rebasing the current branch).
    1.16 +#
    1.17 +# This sample shows how to prevent topic branches that are already
    1.18 +# merged to 'next' branch from getting rebased, because allowing it
    1.19 +# would result in rebasing already published history.
    1.20 +
    1.21 +publish=next
    1.22 +basebranch="$1"
    1.23 +if test "$#" = 2
    1.24 +then
    1.25 +	topic="refs/heads/$2"
    1.26 +else
    1.27 +	topic=`git symbolic-ref HEAD` ||
    1.28 +	exit 0 ;# we do not interrupt rebasing detached HEAD
    1.29 +fi
    1.30 +
    1.31 +case "$topic" in
    1.32 +refs/heads/??/*)
    1.33 +	;;
    1.34 +*)
    1.35 +	exit 0 ;# we do not interrupt others.
    1.36 +	;;
    1.37 +esac
    1.38 +
    1.39 +# Now we are dealing with a topic branch being rebased
    1.40 +# on top of master.  Is it OK to rebase it?
    1.41 +
    1.42 +# Does the topic really exist?
    1.43 +git show-ref -q "$topic" || {
    1.44 +	echo >&2 "No such branch $topic"
    1.45 +	exit 1
    1.46 +}
    1.47 +
    1.48 +# Is topic fully merged to master?
    1.49 +not_in_master=`git-rev-list --pretty=oneline ^master "$topic"`
    1.50 +if test -z "$not_in_master"
    1.51 +then
    1.52 +	echo >&2 "$topic is fully merged to master; better remove it."
    1.53 +	exit 1 ;# we could allow it, but there is no point.
    1.54 +fi
    1.55 +
    1.56 +# Is topic ever merged to next?  If so you should not be rebasing it.
    1.57 +only_next_1=`git-rev-list ^master "^$topic" ${publish} | sort`
    1.58 +only_next_2=`git-rev-list ^master           ${publish} | sort`
    1.59 +if test "$only_next_1" = "$only_next_2"
    1.60 +then
    1.61 +	not_in_topic=`git-rev-list "^$topic" master`
    1.62 +	if test -z "$not_in_topic"
    1.63 +	then
    1.64 +		echo >&2 "$topic is already up-to-date with master"
    1.65 +		exit 1 ;# we could allow it, but there is no point.
    1.66 +	else
    1.67 +		exit 0
    1.68 +	fi
    1.69 +else
    1.70 +	not_in_next=`git-rev-list --pretty=oneline ^${publish} "$topic"`
    1.71 +	perl -e '
    1.72 +		my $topic = $ARGV[0];
    1.73 +		my $msg = "* $topic has commits already merged to public branch:\n";
    1.74 +		my (%not_in_next) = map {
    1.75 +			/^([0-9a-f]+) /;
    1.76 +			($1 => 1);
    1.77 +		} split(/\n/, $ARGV[1]);
    1.78 +		for my $elem (map {
    1.79 +				/^([0-9a-f]+) (.*)$/;
    1.80 +				[$1 => $2];
    1.81 +			} split(/\n/, $ARGV[2])) {
    1.82 +			if (!exists $not_in_next{$elem->[0]}) {
    1.83 +				if ($msg) {
    1.84 +					print STDERR $msg;
    1.85 +					undef $msg;
    1.86 +				}
    1.87 +				print STDERR " $elem->[1]\n";
    1.88 +			}
    1.89 +		}
    1.90 +	' "$topic" "$not_in_next" "$not_in_master"
    1.91 +	exit 1
    1.92 +fi
    1.93 +
    1.94 +exit 0
    1.95 +
    1.96 +################################################################
    1.97 +
    1.98 +This sample hook safeguards topic branches that have been
    1.99 +published from being rewound.
   1.100 +
   1.101 +The workflow assumed here is:
   1.102 +
   1.103 + * Once a topic branch forks from "master", "master" is never
   1.104 +   merged into it again (either directly or indirectly).
   1.105 +
   1.106 + * Once a topic branch is fully cooked and merged into "master",
   1.107 +   it is deleted.  If you need to build on top of it to correct
   1.108 +   earlier mistakes, a new topic branch is created by forking at
   1.109 +   the tip of the "master".  This is not strictly necessary, but
   1.110 +   it makes it easier to keep your history simple.
   1.111 +
   1.112 + * Whenever you need to test or publish your changes to topic
   1.113 +   branches, merge them into "next" branch.
   1.114 +
   1.115 +The script, being an example, hardcodes the publish branch name
   1.116 +to be "next", but it is trivial to make it configurable via
   1.117 +$GIT_DIR/config mechanism.
   1.118 +
   1.119 +With this workflow, you would want to know:
   1.120 +
   1.121 +(1) ... if a topic branch has ever been merged to "next".  Young
   1.122 +    topic branches can have stupid mistakes you would rather
   1.123 +    clean up before publishing, and things that have not been
   1.124 +    merged into other branches can be easily rebased without
   1.125 +    affecting other people.  But once it is published, you would
   1.126 +    not want to rewind it.
   1.127 +
   1.128 +(2) ... if a topic branch has been fully merged to "master".
   1.129 +    Then you can delete it.  More importantly, you should not
   1.130 +    build on top of it -- other people may already want to
   1.131 +    change things related to the topic as patches against your
   1.132 +    "master", so if you need further changes, it is better to
   1.133 +    fork the topic (perhaps with the same name) afresh from the
   1.134 +    tip of "master".
   1.135 +
   1.136 +Let's look at this example:
   1.137 +
   1.138 +		   o---o---o---o---o---o---o---o---o---o "next"
   1.139 +		  /       /           /           /
   1.140 +		 /   a---a---b A     /           /
   1.141 +		/   /               /           /
   1.142 +	       /   /   c---c---c---c B         /
   1.143 +	      /   /   /             \         /
   1.144 +	     /   /   /   b---b C     \       /
   1.145 +	    /   /   /   /             \     /
   1.146 +    ---o---o---o---o---o---o---o---o---o---o---o "master"
   1.147 +
   1.148 +
   1.149 +A, B and C are topic branches.
   1.150 +
   1.151 + * A has one fix since it was merged up to "next".
   1.152 +
   1.153 + * B has finished.  It has been fully merged up to "master" and "next",
   1.154 +   and is ready to be deleted.
   1.155 +
   1.156 + * C has not merged to "next" at all.
   1.157 +
   1.158 +We would want to allow C to be rebased, refuse A, and encourage
   1.159 +B to be deleted.
   1.160 +
   1.161 +To compute (1):
   1.162 +
   1.163 +	git-rev-list ^master ^topic next
   1.164 +	git-rev-list ^master        next
   1.165 +
   1.166 +	if these match, topic has not merged in next at all.
   1.167 +
   1.168 +To compute (2):
   1.169 +
   1.170 +	git-rev-list master..topic
   1.171 +
   1.172 +	if this is empty, it is fully merged to "master".