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