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