4 branch
=`git symbolic-ref HEAD`
5 while case $# in 0) break ;; esac
9 test refs
/heads
/master
= "$branch" ||
{
10 echo >&2 Not on master
17 echo >&2 "Need argument"
21 git rev-parse
--verify "$next" >/dev
/null ||
exit
25 echo >&2 "$0 [--clean | --next test-next ]"
32 master_sha1
=`git rev-parse --verify refs/heads/master`
35 (cd .git
/refs
/heads
&& find -type f
) |
38 -e '/^[^\/][^\/]\//p' |
42 rebase
= done= not_done
= trouble
= date=
43 topic_sha1
=`git rev-parse --verify "refs/heads/$topic"`
45 if test "refs/heads/$topic" = "$branch"
51 git-rev-list -1 --pretty "$topic" |
52 sed -ne 's/^Date: *\(.*\)/ (\1)/p'
55 only_next_1
=`git-rev-list ^master "^$topic" ${next} | sort`
56 only_next_2
=`git-rev-list ^master ${next} | sort`
57 if test "$only_next_1" = "$only_next_2"
59 not_in_topic
=`git-rev-list "^$topic" master`
60 if test -z "$not_in_topic"
64 rebase
=" (can be rebased)"
70 git-rev-list ^master "$topic"
72 test -z "$not_in_master" &&
73 done="${LF}Fully merged -- delete."
77 git-rev-list --pretty=oneline ^${next} "$topic" |
78 sed -e 's/^[0-9a-f]* / - /'
80 if test -n "$not_in_next"
84 # If $topic and master are the same,
86 test "$master_sha1" = "$topic_sha1" ||
87 trouble
="${LF}### MODIFIED AFTER COOKED ###"
89 not_done
="${LF}Still not merged in ${next}$rebase.$LF$not_in_next"
94 not_done
="${LF}Up to date."
97 echo "*** $topic ***$date$is_current$trouble$done$not_done"
99 if test -z "$trouble$not_done" &&
103 git branch
-d "$topic"
109 ################################################################
112 Some important disciplines first.
114 * Once a topic branch forks from
"master", avoid merging
"master"
115 updates into the topic branch unless necessary to resolve conflicts
118 * Once a topic branch is fully cooked and merged into
"master",
119 delete it. If you need to build on top of it to correct
120 earlier mistakes
, create a new topic branch by forking
at the
121 tip of the
"master". This is not strictly necessary
, but it
122 makes it easier to keep your
history simple.
124 * Whenever you need to
test or publish your changes to topic
125 branches
, merge them into
"next" branch.
127 So
, you would want to know
:
129 (1) ...
if a topic branch has ever been merged to
"next". Young
130 topic branches can have stupid mistakes you would rather
131 clean up
, and things that have not been merged into other
132 branches can be easily rebased without affecting others.
134 (2) ...
if a topic branch has been fully merged to
"master".
135 Then you can delete it. More importantly
, you can tell you
136 should not build on top of it.
138 (3) ...
if a topic branch has commits unmerged to
"next". You
139 need to merge them to
test and
/or publish.
141 Let
's look at this example:
143 o---o---o---o---o---o---o---o---o---o "next"
147 / / c---c---c---c B /
151 ---o---o---o---o---o---o---o---o---o---o---o "master"
154 A, B and C are topic branches.
156 * A has one fix since it was merged up to "next".
158 * B has finished. It has been fully merged up to "master" and "next",
159 and is ready to be deleted.
161 * C has not merged to "next" at all.
165 git-rev-list ^master ^topic next
166 git-rev-list ^master next
168 if these match, topic has not merged in next at all.
172 git-rev-list master..topic
174 if this is empty, it is fully merged to "master".
178 git-rev-list next..topic
180 if this is empty, there is nothing to merge to "next".