Rename "master" branch to "main".

All references updated except those outside our control.

Changes

@@ -7,6 +7,8 @@ Revision history for Perl extension App::Sqitch
      - DBI connections to the registry will now be set to trace level one
        when a verbosity level of three or higher is passed to Sqitch
        (i.e., `sqtich -vvv`). Thanks to @wkoszek for the suggestion (#155).
+     - Renamed the "master" branch to "main" and updated all relevant
+       references.
 
 1.1.0  2020-05-17T16:20:07Z
      - Fixed Perl Pod errors, thanks to a pull request from Mohammad S Anwar

lib/sqitch-environment.pod

@@ -64,14 +64,14 @@ variable.
 Username from the original system. Intended for use by scripts that run Sqitch
 from another host, where the originating host username should be passed to the
 execution host, such as
-L<this Docker script|https://github.com/sqitchers/docker-sqitch/blob/master/docker-sqitch.sh>.
+L<this Docker script|https://github.com/sqitchers/docker-sqitch/blob/main/docker-sqitch.sh>.
 
 =item C<SQITCH_ORIG_FULLNAME>
 
 Full name of the original system user. Intended for use by scripts that run
 Sqitch from another host, where the originating host user's identity should be
 passed to the execution host, such as
-L<this Docker script|https://github.com/sqitchers/docker-sqitch/blob/master/docker-sqitch.sh>.
+L<this Docker script|https://github.com/sqitchers/docker-sqitch/blob/main/docker-sqitch.sh>.
 This value will be used only when neither the C<$SQITCH_FULLNAME> nor the
 C<user.name> L<sqitch-config> variable is set.
 
@@ -80,7 +80,7 @@ C<user.name> L<sqitch-config> variable is set.
 Email address of the original user. Intended for use by scripts that run
 Sqitch on a separate host, where the originating host user's identity should
 be passed to the execution host, such as
-L<this Docker script|https://github.com/sqitchers/docker-sqitch/blob/master/docker-sqitch.sh>.
+L<this Docker script|https://github.com/sqitchers/docker-sqitch/blob/main/docker-sqitch.sh>.
 This value will be used only when neither the C<$SQITCH_EMAIL> nor the
 C<user.email> L<sqitch-config> variable is set.
 

lib/sqitchtutorial-exasol.pod

@@ -179,7 +179,7 @@ Let's commit these changes and start creating the database changes.
 
   > git add .
   > git commit -am 'Initialize Sqitch configuration.'
-  [master a42564d] Initialize Sqitch configuration.
+  [main a42564d] Initialize Sqitch configuration.
    2 files changed, 16 insertions(+), 0 deletions(-)
    create mode 100644 sqitch.conf
    create mode 100644 sqitch.plan
@@ -382,7 +382,7 @@ Cool. Now let's commit it.
 
   > git add .
   > git commit -m 'Add flipr schema.'
-  [master 9bee4bd] Add flipr schema.
+  [main 9bee4bd] Add flipr schema.
    5 files changed, 197 insertions(+), 0 deletions(-)
    create mode 100644 deploy/appschema.sql
    create mode 100644 revert/appschema.sql
@@ -460,7 +460,7 @@ We'll see the L<C<rebase>|sqitch-rebase> command a bit later. In the meantime,
 let's commit the new configuration and and make some more changes!
 
   > git commit -am 'Set default deployment target and always verify.'
-  [master 469779a] Set default deployment target and always verify.
+  [main 469779a] Set default deployment target and always verify.
    1 files changed, 8 insertions(+), 0 deletions(-)
 
 =head1 Deploy with Dependency
@@ -609,7 +609,7 @@ Okay, let's commit and deploy again:
 
   > git add .
   > git commit -am 'Add users table.'
-  [master c7c24c5] Add users table.
+  [main c7c24c5] Add users table.
    4 files changed, 18 insertions(+), 0 deletions(-)
    create mode 100644 deploy/users.sql
    create mode 100644 revert/users.sql
@@ -790,7 +790,7 @@ the last deployed change. Looks good. Let's do the commit and re-deploy dance:
 
   > git add .
   > git commit -m 'Add flips table and userflips view.'
-  [master c40f23f] Add flips table and userflips view.
+  [main c40f23f] Add flips table and userflips view.
    7 files changed, 41 insertions(+), 0 deletions(-)
    create mode 100644 deploy/flips.sql
    create mode 100644 deploy/userflips.sql
@@ -832,7 +832,7 @@ to have it go out with deployments tied to the release, let's tag it:
   > sqitch tag v1.0.0-dev1 -n 'Tag v1.0.0-dev1.'
   Tagged "userflips" with @v1.0.0-dev1
   > git commit -am 'Tag the database with v1.0.0-dev1.'
-  [master b07ce3d] Tag the database with v1.0.0-dev1.
+  [main b07ce3d] Tag the database with v1.0.0-dev1.
    1 files changed, 1 insertions(+), 0 deletions(-)
   > git tag v1.0.0-dev1 -am 'Tag v1.0.0-dev1'
 
@@ -965,14 +965,14 @@ Great! Now make it so:
    create mode 100644 revert/hashtags.sql
    create mode 100644 verify/hashtags.sql
 
-Good, we've finished this feature. Time to merge back into C<master>.
+Good, we've finished this feature. Time to merge back into C<main>.
 
 =head2 Emergency
 
 Let's do it:
 
-  > git checkout master
-  Switched to branch 'master'
+  > git checkout main
+  Switched to branch 'main'
   > git pull
   Updating b07ce3d..05d3e5d
   Fast-forward
@@ -985,7 +985,7 @@ Let's do it:
    create mode 100644 revert/lists.sql
    create mode 100644 verify/lists.sql
 
-Hrm, that's interesting. Looks like someone made some changes to C<master>.
+Hrm, that's interesting. Looks like someone made some changes to C<main>.
 They added list support. Well, let's see what happens when we merge our
 changes.
 
@@ -998,38 +998,38 @@ Oh, a conflict in F<sqitch.plan>. Not too surprising, since both the merged
 C<lists> branch and our C<hashtags> branch added changes to the plan. Let's
 try a different approach.
 
-The truth is, we got lazy. Those changes when we pulled master from the origin
+The truth is, we got lazy. Those changes when we pulled main from the origin
 should have raised a red flag. It's considered a bad practice not to look at
-what's changed in C<master> before merging in a branch. What one I<should> do
+what's changed in C<main> before merging in a branch. What one I<should> do
 is either:
 
 =over
 
 =item *
 
-Rebase the F<hashtags> branch from master before merging. This "rewinds" the
-branch changes, pulls from C<master>, and then replays the changes back on top
+Rebase the F<hashtags> branch from main before merging. This "rewinds" the
+branch changes, pulls from C<main>, and then replays the changes back on top
 of the pulled changes.
 
 =item *
 
-Create a patch and apply I<that> to master. This is the sort of thing you
+Create a patch and apply I<that> to main. This is the sort of thing you
 might have to do if you're sending changes to another user, especially if the
 VCS is not Git.
 
 =back
 
-So let's restore things to how they were at master:
+So let's restore things to how they were at main:
 
   > git reset --hard HEAD
   HEAD is now at 05d3e5d Merge branch 'lists'
 
 That throws out our botched merge. Now let's go back to our branch and rebase
-it on C<master>:
+it on C<main>:
 
   > git checkout hashtags
   Switched to branch 'hashtags'
-  > git rebase master
+  > git rebase main
   First, rewinding head to replay your work on top of it...
   Applying: Add hashtags table.
   Using index info to reconstruct a base tree...
@@ -1073,7 +1073,7 @@ Now add the union merge driver to F<.gitattributes> for F<sqitch.plan>
 and rebase again:
 
   > echo sqitch.plan merge=union > .gitattributes
-  > git rebase master
+  > git rebase main
   First, rewinding head to replay your work on top of it...
   Applying: Add hashtags table.
   Using index info to reconstruct a base tree...
@@ -1132,10 +1132,10 @@ worthwhile to keep that change:
 
 =head2 Merges Mastered
 
-And now, finally, we can merge into C<master>:
+And now, finally, we can merge into C<main>:
 
-  > git checkout master
-  Switched to branch 'master'
+  > git checkout main
+  Switched to branch 'main'
   > git merge --no-ff hashtags -m "Merge branch 'hashtags'"
   Merge made by recursive.
    .gitattributes      |    1 +
@@ -1165,14 +1165,14 @@ And double-check our work:
   lists [appschema users] 2014-09-05T17:33:43Z Marge N. O’Vera <marge@example.com> # Adds table for storing lists.
   hashtags [appschema flips] 2014-09-05T17:39:53Z Marge N. O’Vera <marge@example.com> # Adds table for storing hashtags.
 
-Much much better, a nice clean master now. And because it is now identical to
+Much much better, a nice clean main now. And because it is now identical to
 the "hashtags" branch, we can just carry on. Go ahead and tag it, bundle, and
 release:
 
   > sqitch tag v1.0.0-dev2 -n 'Tag v1.0.0-dev2.'
   Tagged "hashtags" with @v1.0.0-dev2
   > git commit -am 'Tag the database with v1.0.0-dev2.'
-  [master 8a6a73b] Tag the database with v1.0.0-dev2.
+  [main 8a6a73b] Tag the database with v1.0.0-dev2.
    1 files changed, 1 insertions(+), 0 deletions(-)
   > git tag v1.0.0-dev2 -am 'Tag v1.0.0-dev2'
   > sqitch bundle --dest-dir flipr-1.0.0-dev2
@@ -1260,7 +1260,7 @@ point of fact, it has copied the files to stand in for the previous instance
 of the C<userflips> change, which we can see via C<git status>:
 
   > git status
-  # On branch master
+  # On branch main
   # Changed but not updated:
   #   (use "git add <file>..." to update what will be committed)
   #   (use "git checkout -- <file>..." to discard changes in working directory)
@@ -1370,7 +1370,7 @@ Excellent. Let's go ahead and commit these changes:
 
   > git add .
   > git commit -m 'Add the twitter column to the userflips view.'
-  [master 95d6dd0] Add the twitter column to the userflips view.
+  [main 95d6dd0] Add the twitter column to the userflips view.
    7 files changed, 30 insertions(+), 4 deletions(-)
    create mode 100644 deploy/userflips@v1.0.0-dev2.sql
    create mode 100644 revert/userflips@v1.0.0-dev2.sql