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".