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