d@0: #!/bin/sh d@0: # d@0: # Copyright (c) 2006, 2008 Junio C Hamano d@0: # d@0: # The "pre-rebase" hook is run just before "git rebase" starts doing d@0: # its job, and can prevent the command from running by exiting with d@0: # non-zero status. d@0: # d@0: # The hook is called with the following parameters: d@0: # d@0: # $1 -- the upstream the series was forked from. d@0: # $2 -- the branch being rebased (or empty when rebasing the current branch). d@0: # d@0: # This sample shows how to prevent topic branches that are already d@0: # merged to 'next' branch from getting rebased, because allowing it d@0: # would result in rebasing already published history. d@0: d@0: publish=next d@0: basebranch="$1" d@0: if test "$#" = 2 d@0: then d@0: topic="refs/heads/$2" d@0: else d@0: topic=`git symbolic-ref HEAD` || d@0: exit 0 ;# we do not interrupt rebasing detached HEAD d@0: fi d@0: d@0: case "$topic" in d@0: refs/heads/??/*) d@0: ;; d@0: *) d@0: exit 0 ;# we do not interrupt others. d@0: ;; d@0: esac d@0: d@0: # Now we are dealing with a topic branch being rebased d@0: # on top of master. Is it OK to rebase it? d@0: d@0: # Does the topic really exist? d@0: git show-ref -q "$topic" || { d@0: echo >&2 "No such branch $topic" d@0: exit 1 d@0: } d@0: d@0: # Is topic fully merged to master? d@0: not_in_master=`git rev-list --pretty=oneline ^master "$topic"` d@0: if test -z "$not_in_master" d@0: then d@0: echo >&2 "$topic is fully merged to master; better remove it." d@0: exit 1 ;# we could allow it, but there is no point. d@0: fi d@0: d@0: # Is topic ever merged to next? If so you should not be rebasing it. d@0: only_next_1=`git rev-list ^master "^$topic" ${publish} | sort` d@0: only_next_2=`git rev-list ^master ${publish} | sort` d@0: if test "$only_next_1" = "$only_next_2" d@0: then d@0: not_in_topic=`git rev-list "^$topic" master` d@0: if test -z "$not_in_topic" d@0: then d@0: echo >&2 "$topic is already up-to-date with master" d@0: exit 1 ;# we could allow it, but there is no point. d@0: else d@0: exit 0 d@0: fi d@0: else d@0: not_in_next=`git rev-list --pretty=oneline ^${publish} "$topic"` d@0: /usr/bin/perl -e ' d@0: my $topic = $ARGV[0]; d@0: my $msg = "* $topic has commits already merged to public branch:\n"; d@0: my (%not_in_next) = map { d@0: /^([0-9a-f]+) /; d@0: ($1 => 1); d@0: } split(/\n/, $ARGV[1]); d@0: for my $elem (map { d@0: /^([0-9a-f]+) (.*)$/; d@0: [$1 => $2]; d@0: } split(/\n/, $ARGV[2])) { d@0: if (!exists $not_in_next{$elem->[0]}) { d@0: if ($msg) { d@0: print STDERR $msg; d@0: undef $msg; d@0: } d@0: print STDERR " $elem->[1]\n"; d@0: } d@0: } d@0: ' "$topic" "$not_in_next" "$not_in_master" d@0: exit 1 d@0: fi d@0: d@0: exit 0 d@0: d@0: ################################################################ d@0: d@0: This sample hook safeguards topic branches that have been d@0: published from being rewound. d@0: d@0: The workflow assumed here is: d@0: d@0: * Once a topic branch forks from "master", "master" is never d@0: merged into it again (either directly or indirectly). d@0: d@0: * Once a topic branch is fully cooked and merged into "master", d@0: it is deleted. If you need to build on top of it to correct d@0: earlier mistakes, a new topic branch is created by forking at d@0: the tip of the "master". This is not strictly necessary, but d@0: it makes it easier to keep your history simple. d@0: d@0: * Whenever you need to test or publish your changes to topic d@0: branches, merge them into "next" branch. d@0: d@0: The script, being an example, hardcodes the publish branch name d@0: to be "next", but it is trivial to make it configurable via d@0: $GIT_DIR/config mechanism. d@0: d@0: With this workflow, you would want to know: d@0: d@0: (1) ... if a topic branch has ever been merged to "next". Young d@0: topic branches can have stupid mistakes you would rather d@0: clean up before publishing, and things that have not been d@0: merged into other branches can be easily rebased without d@0: affecting other people. But once it is published, you would d@0: not want to rewind it. d@0: d@0: (2) ... if a topic branch has been fully merged to "master". d@0: Then you can delete it. More importantly, you should not d@0: build on top of it -- other people may already want to d@0: change things related to the topic as patches against your d@0: "master", so if you need further changes, it is better to d@0: fork the topic (perhaps with the same name) afresh from the d@0: tip of "master". d@0: d@0: Let's look at this example: d@0: d@0: o---o---o---o---o---o---o---o---o---o "next" d@0: / / / / d@0: / a---a---b A / / d@0: / / / / d@0: / / c---c---c---c B / d@0: / / / \ / d@0: / / / b---b C \ / d@0: / / / / \ / d@0: ---o---o---o---o---o---o---o---o---o---o---o "master" d@0: d@0: d@0: A, B and C are topic branches. d@0: d@0: * A has one fix since it was merged up to "next". d@0: d@0: * B has finished. It has been fully merged up to "master" and "next", d@0: and is ready to be deleted. d@0: d@0: * C has not merged to "next" at all. d@0: d@0: We would want to allow C to be rebased, refuse A, and encourage d@0: B to be deleted. d@0: d@0: To compute (1): d@0: d@0: git rev-list ^master ^topic next d@0: git rev-list ^master next d@0: d@0: if these match, topic has not merged in next at all. d@0: d@0: To compute (2): d@0: d@0: git rev-list master..topic d@0: d@0: if this is empty, it is fully merged to "master".