fix: test

spec/fixtures/test.git/HEAD

@@ -1 +1 @@
-ref: refs/heads/main
+ref: refs/heads/master

spec/fixtures/test.git/hooks/pre-rebase.sample

@@ -34,31 +34,31 @@ refs/heads/??/*)
 esac
 
 # Now we are dealing with a topic branch being rebased
-# on top of main.  Is it OK to rebase it?
+# on top of master.  Is it OK to rebase it?
 
 # Does the topic really exist?
 git show-ref -q "$topic" || {
 	echo >&2 "No such branch $topic"
 	exit 1
 }
 
-# Is topic fully merged to main?
-not_in_main=`git rev-list --pretty=oneline ^main "$topic"`
-if test -z "$not_in_main"
+# Is topic fully merged to master?
+not_in_master=`git rev-list --pretty=oneline ^master "$topic"`
+if test -z "$not_in_master"
 then
-	echo >&2 "$topic is fully merged to main; better remove it."
+	echo >&2 "$topic is fully merged to master; better remove it."
 	exit 1 ;# we could allow it, but there is no point.
 fi
 
 # Is topic ever merged to next?  If so you should not be rebasing it.
-only_next_1=`git rev-list ^main "^$topic" ${publish} | sort`
-only_next_2=`git rev-list ^main           ${publish} | sort`
+only_next_1=`git rev-list ^master "^$topic" ${publish} | sort`
+only_next_2=`git rev-list ^master           ${publish} | sort`
 if test "$only_next_1" = "$only_next_2"
 then
-	not_in_topic=`git rev-list "^$topic" main`
+	not_in_topic=`git rev-list "^$topic" master`
 	if test -z "$not_in_topic"
 	then
-		echo >&2 "$topic is already up to date with main"
+		echo >&2 "$topic is already up to date with master"
 		exit 1 ;# we could allow it, but there is no point.
 	else
 		exit 0
@@ -84,7 +84,7 @@ else
 				print STDERR " $elem->[1]\n";
 			}
 		}
-	' "$topic" "$not_in_next" "$not_in_main"
+	' "$topic" "$not_in_next" "$not_in_master"
 	exit 1
 fi
 
@@ -95,13 +95,13 @@ published from being rewound.
 
 The workflow assumed here is:
 
- * Once a topic branch forks from "main", "main" is never
+ * Once a topic branch forks from "master", "master" is never
    merged into it again (either directly or indirectly).
 
- * Once a topic branch is fully cooked and merged into "main",
+ * Once a topic branch is fully cooked and merged into "master",
    it is deleted.  If you need to build on top of it to correct
    earlier mistakes, a new topic branch is created by forking at
-   the tip of the "main".  This is not strictly necessary, but
+   the tip of the "master".  This is not strictly necessary, but
    it makes it easier to keep your history simple.
 
  * Whenever you need to test or publish your changes to topic
@@ -120,13 +120,13 @@ With this workflow, you would want to know:
     affecting other people.  But once it is published, you would
     not want to rewind it.
 
-(2) ... if a topic branch has been fully merged to "main".
+(2) ... if a topic branch has been fully merged to "master".
     Then you can delete it.  More importantly, you should not
     build on top of it -- other people may already want to
     change things related to the topic as patches against your
-    "main", so if you need further changes, it is better to
+    "master", so if you need further changes, it is better to
     fork the topic (perhaps with the same name) afresh from the
-    tip of "main".
+    tip of "master".
 
 Let's look at this example:
 
@@ -138,14 +138,14 @@ Let's look at this example:
 	      /   /   /             \         /
 	     /   /   /   b---b C     \       /
 	    /   /   /   /             \     /
-    ---o---o---o---o---o---o---o---o---o---o---o "main"
+    ---o---o---o---o---o---o---o---o---o---o---o "master"
 
 
 A, B and C are topic branches.
 
  * A has one fix since it was merged up to "next".
 
- * B has finished.  It has been fully merged up to "main" and "next",
+ * B has finished.  It has been fully merged up to "master" and "next",
    and is ready to be deleted.
 
  * C has not merged to "next" at all.
@@ -155,15 +155,15 @@ B to be deleted.
 
 To compute (1):
 
-	git rev-list ^main ^topic next
-	git rev-list ^main        next
+	git rev-list ^master ^topic next
+	git rev-list ^master        next
 
 	if these match, topic has not merged in next at all.
 
 To compute (2):
 
-	git rev-list main..topic
+	git rev-list master..topic
 
-	if this is empty, it is fully merged to "main".
+	if this is empty, it is fully merged to "master".
 
 DOC_END