diff --git a/Changes b/Changes index 5a42d147a..eb3e8d27e 100644 --- a/Changes +++ b/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 diff --git a/lib/sqitch-environment.pod b/lib/sqitch-environment.pod index a4069ede1..389b14420 100644 --- a/lib/sqitch-environment.pod +++ b/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. +L. =item C 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. +L. This value will be used only when neither the C<$SQITCH_FULLNAME> nor the C L variable is set. @@ -80,7 +80,7 @@ C L 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. +L. This value will be used only when neither the C<$SQITCH_EMAIL> nor the C L variable is set. diff --git a/lib/sqitchtutorial-exasol.pod b/lib/sqitchtutorial-exasol.pod index 222d2fec0..50d816711 100644 --- a/lib/sqitchtutorial-exasol.pod +++ b/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|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. +Good, we've finished this feature. Time to merge back into C
. =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. +Hrm, that's interesting. Looks like someone made some changes to C
. They added list support. Well, let's see what happens when we merge our changes. @@ -998,38 +998,38 @@ Oh, a conflict in F. Not too surprising, since both the merged C branch and our C 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 before merging in a branch. What one I do +what's changed in C
before merging in a branch. What one I do is either: =over =item * -Rebase the F branch from master before merging. This "rewinds" the -branch changes, pulls from C, and then replays the changes back on top +Rebase the F branch from main before merging. This "rewinds" the +branch changes, pulls from C
, and then replays the changes back on top of the pulled changes. =item * -Create a patch and apply I to master. This is the sort of thing you +Create a patch and apply I 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: +it on C
: > 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 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: +And now, finally, we can merge into C
: - > 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 # Adds table for storing lists. hashtags [appschema flips] 2014-09-05T17:39:53Z Marge N. O’Vera # 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 change, which we can see via C: > git status - # On branch master + # On branch main # Changed but not updated: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." 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 diff --git a/lib/sqitchtutorial-firebird.pod b/lib/sqitchtutorial-firebird.pod index 8f11a8d86..36ee3fb0e 100644 --- a/lib/sqitchtutorial-firebird.pod +++ b/lib/sqitchtutorial-firebird.pod @@ -44,7 +44,7 @@ source code repository. So let's do that with Git: > touch README.md > git add . > git commit -am 'Initialize project, add README.' - [master (root-commit) 761ffcd] Initialize project, add README. + [main (root-commit) 761ffcd] Initialize project, add README. 1 files changed, 39 insertions(+), 0 deletions(-) create mode 100644 README.md @@ -138,7 +138,7 @@ Let's commit these changes and start creating the database changes. > git add . > git commit -am 'Initialize Sqitch configuration.' - [master 2177ce4] Initialize Sqitch configuration. + [main 2177ce4] Initialize Sqitch configuration. 2 files changed, 19 insertions(+), 0 deletions(-) create mode 100644 sqitch.conf create mode 100644 sqitch.plan @@ -371,7 +371,7 @@ Cool. Now let's commit it. > git add . > git commit -m 'Add users table.' - [master ec72105] Add users table. + [main ec72105] Add users table. 4 files changed, 24 insertions(+), 0 deletions(-) create mode 100644 deploy/users.sql create mode 100644 revert/users.sql @@ -445,7 +445,7 @@ We'll see the L|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 target and always verify.' - [master cfc9fea] Set default target and always verify. + [main cfc9fea] Set default target and always verify. 1 files changed, 8 insertions(+), 0 deletions(-) =head1 Deploy with Dependency @@ -594,7 +594,7 @@ Okay, let's commit and deploy again: > git add . > git commit -am 'Add flips table.' - [master 09c636c] Add flips table. + [main 09c636c] Add flips table. 4 files changed, 24 insertions(+), 0 deletions(-) create mode 100644 deploy/flips.sql create mode 100644 revert/flips.sql @@ -664,7 +664,7 @@ Looks good! Commit it. > git add . > git commit -m 'Add the userflips view.' - [master 28ffa63] Add the userflips view. + [main 28ffa63] Add the userflips view. 4 files changed, 23 insertions(+), 0 deletions(-) create mode 100644 deploy/userflips.sql create mode 100644 revert/userflips.sql @@ -679,7 +679,7 @@ 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 696a891] Tag the database with v1.0.0-dev1. + [main 696a891] 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' @@ -808,14 +808,14 @@ Note the use of C<--show-tags> to show all the deployed tags. 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. +Good, we've finished this feature. Time to merge back into C
. =head2 Emergency Let's do it: - > git checkout master - Switched to branch 'master' + > git checkout main + Switched to branch 'main' > git pull Updating 696a891..9af80a1 Fast-forward @@ -828,7 +828,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. +Hrm, that's interesting. Looks like someone made some changes to C
. They added list support. Well, let's see what happens when we merge our changes. @@ -841,38 +841,38 @@ Oh, a conflict in F. Not too surprising, since both the merged C branch and our C 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 before merging in a branch. What one I do +what's changed in C
before merging in a branch. What one I do is either: =over =item * -Rebase the F branch from master before merging. This "rewinds" the -branch changes, pulls from C, and then replays the changes back on top +Rebase the F branch from main before merging. This "rewinds" the +branch changes, pulls from C
, and then replays the changes back on top of the pulled changes. =item * -Create a patch and apply I to master. This is the sort of thing you +Create a patch and apply I 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 d5e7e86 Merge branch 'lists' That throws out our botched merge. Now let's go back to our branch and rebase -it on C: +it on C
: > 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... @@ -915,7 +915,7 @@ Now add the union merge driver to F<.gitattributes> for F 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... @@ -969,10 +969,10 @@ worthwhile to keep that change: =head2 Merges Mastered -And now, finally, we can merge into C: +And now, finally, we can merge into C
: - > 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 + @@ -1001,14 +1001,14 @@ And double-check our work: lists [flips] 2014-01-05T22:44:41Z Marge N. O’Vera # Adds table for storing lists. hashtags [flips] 2014-01-05T22:54:27Z Marge N. O’Vera # 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 7d07ee3] Tag the database with v1.0.0-dev2. + [main 7d07ee3] Tag the database with v1.0.0-dev2. 1 file changed, 1 insertion(+) > git tag v1.0.0-dev2 -am 'Tag v1.0.0-dev2' > sqitch bundle --dest-dir flipr-1.0.0-dev2 @@ -1095,8 +1095,8 @@ point of fact, it has copied the files to stand in for the previous instance of the C change, which we can see via C: > git status - # On branch master - # Your branch is ahead of 'origin/master' by 4 commits. + # On branch main + # Your branch is ahead of 'origin/main' by 4 commits. # (use "git push" to publish your local commits) # # Changes not staged for commit: @@ -1220,7 +1220,7 @@ Excellent. Let's go ahead and commit these changes: > rm -rf flipr-1.0.0-dev2 > git add . > git commit -m 'Add the twitter column to the userflips view.' - [master f530359] Add the twitter column to the userflips view. + [main f530359] Add the twitter column to the userflips view. 7 files changed, 32 insertions(+), 4 deletions(-) create mode 100644 deploy/userflips@v1.0.0-dev2.sql create mode 100644 revert/userflips@v1.0.0-dev2.sql diff --git a/lib/sqitchtutorial-mysql.pod b/lib/sqitchtutorial-mysql.pod index 19f72d679..3b79ee89a 100644 --- a/lib/sqitchtutorial-mysql.pod +++ b/lib/sqitchtutorial-mysql.pod @@ -44,7 +44,7 @@ source code repository. So let's do that with Git: > touch README.md > git add . > git commit -am 'Initialize project, add README.' - [master (root-commit) fdf2a40] Initialize project, add README. + [main (root-commit) fdf2a40] Initialize project, add README. 1 file changed, 38 insertions(+) create mode 100644 README.md @@ -128,7 +128,7 @@ Let's commit these changes and start creating the database changes. > git add . > git commit -am 'Initialize Sqitch configuration.' - [master 79fe2cc] Initialize Sqitch configuration. + [main 79fe2cc] Initialize Sqitch configuration. 2 files changed, 19 insertions(+) create mode 100644 sqitch.conf create mode 100644 sqitch.plan @@ -347,7 +347,7 @@ Cool. Now let's commit it. > git add . > git commit -m 'Add the "flipr" user.' - [master c63acb9] Add the "flipr" user. + [main c63acb9] Add the "flipr" user. 4 files changed, 23 insertions(+) create mode 100644 deploy/appuser.sql create mode 100644 revert/appuser.sql @@ -424,7 +424,7 @@ We'll see the L|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 target and always verify.' - [master c793050] Set default target and always verify. + [main c793050] Set default target and always verify. 1 file changed, 8 insertions(+) =head1 Deploy with Dependency @@ -577,7 +577,7 @@ Okay, let's commit and deploy again: > git add . > git commit -am 'Add users table.' - [master 7c99fb0] Add users table. + [main 7c99fb0] Add users table. 4 files changed, 31 insertions(+) create mode 100644 deploy/users.sql create mode 100644 revert/users.sql @@ -775,7 +775,7 @@ the last deployed change. Looks good. Let's do the commit and re-deploy dance: > git add . > git commit -m 'Add `insert_user()` and `change_pass()`.' - [master 0f95e13] Add `insert_user()` and `change_pass()`. + [main 0f95e13] Add `insert_user()` and `change_pass()`. 7 files changed, 86 insertions(+) create mode 100644 deploy/change_pass.sql create mode 100644 deploy/insert_user.sql @@ -817,7 +817,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 "change_pass" with @v1.0.0-dev1 > git commit -am 'Tag the database with v1.0.0-dev1.' - [master 0595297] Tag the database with v1.0.0-dev1. + [main 0595297] Tag the database with v1.0.0-dev1. 1 file changed, 1 insertion(+) > git tag v1.0.0-dev1 -am 'Tag v1.0.0-dev1' @@ -1105,14 +1105,14 @@ should end up looking something like this: # Nothing to deploy (up-to-date) -Good, we've finished this feature. Time to merge back into C. +Good, we've finished this feature. Time to merge back into C
. =head2 Emergency Let's do it: - > git checkout master - Switched to branch 'master' + > git checkout main + Switched to branch 'main' > git pull Updating 0595297..5a58089 Fast-forward @@ -1137,7 +1137,7 @@ Let's do it: create mode 100644 verify/insert_list.sql create mode 100644 verify/lists.sql -Hrm, that's interesting. Looks like someone made some changes to C. +Hrm, that's interesting. Looks like someone made some changes to C
. They added list support. Well, let's see what happens when we merge our changes. @@ -1150,38 +1150,38 @@ Oh, a conflict in F. Not too surprising, since both the merged C branch and our C 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 before merging in a branch. What one I do +what's changed in C
before merging in a branch. What one I do is either: =over =item * -Rebase the F branch from master before merging. This "rewinds" the -branch changes, pulls from C, and then replays the changes back on top +Rebase the F branch from main before merging. This "rewinds" the +branch changes, pulls from C
, and then replays the changes back on top of the pulled changes. =item * -Create a patch and apply I to master. This is the sort of thing you +Create a patch and apply I 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 5a58089 Merge branch 'lists' That throws out our botched merge. Now let's go back to our branch and rebase -it on C: +it on C
: > git checkout flips Switched to branch 'flips' - > git rebase master + > git rebase main First, rewinding head to replay your work on top of it... Applying: Add flips table. Using index info to reconstruct a base tree... @@ -1224,7 +1224,7 @@ Now add the union merge driver to F<.gitattributes> for F 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 flips table. Using index info to reconstruct a base tree... @@ -1296,10 +1296,10 @@ worthwhile to keep that change: =head2 Merges Mastered -And now, finally, we can merge into C: +And now, finally, we can merge into C
: - > git checkout master - Switched to branch 'master' + > git checkout main + Switched to branch 'main' > git merge --no-ff flips -m "Merge branch 'flips'" Merge made by the 'recursive' strategy. .gitattributes | 1 + @@ -1345,14 +1345,14 @@ And double-check our work: insert_flip [flips appuser] 2013-12-31T21:56:12Z Marge N. O’Vera # Creates a function to insert a flip. delete_flip [flips appuser] 2013-12-31T21:56:22Z Marge N. O’Vera # Creates a function to delete a flip. -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 "flips" 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 "delete_flip" with @v1.0.0-dev2 > git commit -am 'Tag the database with v1.0.0-dev2.' - [master 76d6e15] Tag the database with v1.0.0-dev2. + [main 76d6e15] Tag the database with v1.0.0-dev2. 1 file changed, 1 insertion(+) > git tag v1.0.0-dev2 -am 'Tag v1.0.0-dev2' > sqitch bundle --dest-dir flipr-1.0.0-dev2 @@ -1461,8 +1461,8 @@ point of fact, it has copied the files to stand in for the previous instance of the C change, which we can see via C: > git status - # On branch master - # Your branch is ahead of 'origin/master' by 5 commits. + # On branch main + # Your branch is ahead of 'origin/main' by 5 commits. # (use "git push" to publish your local commits) # # Changes not staged for commit: @@ -1673,7 +1673,7 @@ Excellent. Let's go ahead and commit these changes: > git add . > git commit -m 'Use encrypt() to encrypt passwords.' - [master abcce73] Use encrypt() to encrypt passwords. + [main abcce73] Use encrypt() to encrypt passwords. 13 files changed, 137 insertions(+), 9 deletions(-) create mode 100644 deploy/change_pass@v1.0.0-dev2.sql create mode 100644 deploy/insert_user@v1.0.0-dev2.sql diff --git a/lib/sqitchtutorial-oracle.pod b/lib/sqitchtutorial-oracle.pod index feeabd6b4..326c788e6 100644 --- a/lib/sqitchtutorial-oracle.pod +++ b/lib/sqitchtutorial-oracle.pod @@ -86,7 +86,7 @@ source code repository. So let's do that with Git: > touch README.md > git add . > git commit -am 'Initialize project, add README.' - [master (root-commit) 1bd134b] Initialize project, add README. + [main (root-commit) 1bd134b] Initialize project, add README. 1 file changed, 38 insertions(+) create mode 100644 README.md @@ -159,7 +159,7 @@ Let's commit these changes and start creating the database changes. > git add . > git commit -am 'Initialize Sqitch configuration.' - [master bd82f41] Initialize Sqitch configuration. + [main bd82f41] Initialize Sqitch configuration. 2 files changed, 19 insertions(+) create mode 100644 sqitch.conf create mode 100644 sqitch.plan @@ -388,7 +388,7 @@ Cool. Now let's commit it. > git add . > git commit -m 'Add flipr schema.' - [master e0e0b11] Add flipr schema. + [main e0e0b11] Add flipr schema. 4 files changed, 11 insertions(+) create mode 100644 deploy/appschema.sql create mode 100644 revert/appschema.sql @@ -464,7 +464,7 @@ We'll see the L|sqitch-rebase> command a bit later. In the meantime, let's commit the new configuration and make some more changes! > git commit -am 'Set default target and always verify.' - [master c4a308a] Set default target and always verify. + [main c4a308a] Set default target and always verify. 1 file changed, 8 insertions(+) =head1 Deploy with Dependency @@ -619,7 +619,7 @@ Okay, let's commit and deploy again: > git add . > git commit -am 'Add users table.' - [master 2506312] Add users table. + [main 2506312] Add users table. 4 files changed, 17 insertions(+) create mode 100644 deploy/users.sql create mode 100644 revert/users.sql @@ -855,7 +855,7 @@ the last deployed change. Looks good. Let's do the commit and re-deploy dance: > git add . > git commit -m 'Add `insert_user()` and `change_pass()`.' - [master 6b6797e] Add `insert_user()` and `change_pass()`. + [main 6b6797e] Add `insert_user()` and `change_pass()`. 7 files changed, 92 insertions(+) create mode 100644 deploy/change_pass.sql create mode 100644 deploy/insert_user.sql @@ -899,7 +899,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 "change_pass" with @v1.0.0-dev1 > git commit -am 'Tag the database with v1.0.0-dev1.' - [master eae5f71] Tag the database with v1.0.0-dev1. + [main eae5f71] Tag the database with v1.0.0-dev1. 1 file changed, 1 insertion(+) > git tag v1.0.0-dev1 -am 'Tag v1.0.0-dev1' @@ -1162,14 +1162,14 @@ should end up looking something like this: # Nothing to deploy (up-to-date) -Good, we've finished this feature. Time to merge back into C. +Good, we've finished this feature. Time to merge back into C
. =head2 Emergency Let's do it: - > git checkout master - Switched to branch 'master' + > git checkout main + Switched to branch 'main' > git pull Updating eae5f71..a16f97c Fast-forward @@ -1194,7 +1194,7 @@ Let's do it: create mode 100644 verify/insert_list.sql create mode 100644 verify/lists.sql -Hrm, that's interesting. Looks like someone made some changes to C. +Hrm, that's interesting. Looks like someone made some changes to C
. They added list support. Well, let's see what happens when we merge our changes. @@ -1207,38 +1207,38 @@ Oh, a conflict in F. Not too surprising, since both the merged C branch and our C 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 before merging in a branch. What one I do +what's changed in C
before merging in a branch. What one I do is either: =over =item * -Rebase the F branch from master before merging. This "rewinds" the -branch changes, pulls from C, and then replays the changes back on top +Rebase the F branch from main before merging. This "rewinds" the +branch changes, pulls from C
, and then replays the changes back on top of the pulled changes. =item * -Create a patch and apply I to master. This is the sort of thing you +Create a patch and apply I 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 a16f97c Merge branch 'lists' That throws out our botched merge. Now let's go back to our branch and rebase -it on C: +it on C
: > git checkout flips Switched to branch 'flips' - > git rebase master + > git rebase main First, rewinding head to replay your work on top of it... Applying: Add flips table. Using index info to reconstruct a base tree... @@ -1281,7 +1281,7 @@ Now add the union merge driver to F<.gitattributes> for F 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 flips table. Using index info to reconstruct a base tree... @@ -1359,10 +1359,10 @@ worthwhile to keep that change: =head2 Merges Mastered -And now, finally, we can merge into C: +And now, finally, we can merge into C
: - > git checkout master - Switched to branch 'master' + > git checkout main + Switched to branch 'main' > git merge --no-ff flips -m "Merge branch 'flips'" Merge made by the 'recursive' strategy. .gitattributes | 1 + @@ -1408,14 +1408,14 @@ And double-check our work: insert_flip [flips appschema] 2014-01-01T00:53:00Z Marge N. O’Vera # Creates a function to insert a flip. delete_flip [flips appschema] 2014-01-01T00:53:16Z Marge N. O’Vera # Creates a function to delete a flip. -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 "flips" 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 "delete_flip" with @v1.0.0-dev2 > git commit -am 'Tag the database with v1.0.0-dev2.' - [master 5427456] Tag the database with v1.0.0-dev2. + [main 5427456] Tag the database with v1.0.0-dev2. 1 file changed, 1 insertion(+) > git tag v1.0.0-dev2 -am 'Tag v1.0.0-dev2' > sqitch bundle --dest-dir flipr-1.0.0-dev2 @@ -1597,8 +1597,8 @@ point of fact, it has copied the files to stand in for the previous instance of the C change, which we can see via C: > git status - # On branch master - # Your branch is ahead of 'origin/master' by 2 commits. + # On branch main + # Your branch is ahead of 'origin/main' by 2 commits. # (use "git push" to publish your local commits) # # Changes not staged for commit: @@ -1815,7 +1815,7 @@ Excellent. Let's go ahead and commit these changes: > git add . > git commit -m 'Use crypt to encrypt passwords.' - [master be46175] Use crypt to encrypt passwords. + [main be46175] Use crypt to encrypt passwords. 13 files changed, 181 insertions(+), 15 deletions(-) create mode 100644 deploy/change_pass@v1.0.0-dev2.sql create mode 100644 deploy/insert_user@v1.0.0-dev2.sql diff --git a/lib/sqitchtutorial-snowflake.pod b/lib/sqitchtutorial-snowflake.pod index f4ce09963..8f3629651 100644 --- a/lib/sqitchtutorial-snowflake.pod +++ b/lib/sqitchtutorial-snowflake.pod @@ -146,7 +146,7 @@ Let's commit these changes and start creating the database changes. > git add . > git commit -am 'Initialize Sqitch configuration.' - [master b731cc3] Initialize Sqitch configuration. + [main b731cc3] Initialize Sqitch configuration. 2 files changed, 15 insertions(+) create mode 100644 sqitch.conf create mode 100644 sqitch.plan @@ -386,7 +386,7 @@ Cool. Now let's commit it. > git add . > git commit -m 'Add flipr schema.' - [master 7fd5ace] Add flipr schema. + [main 7fd5ace] Add flipr schema. 4 files changed, 10 insertions(+) create mode 100644 deploy/appschema.sql create mode 100644 revert/appschema.sql @@ -465,7 +465,7 @@ We'll see the L|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 3834a8d] Set default deployment target and always verify. + [main 3834a8d] Set default deployment target and always verify. 1 files changed, 8 insertions(+), 0 deletions(-) =head1 Deploy with Dependency @@ -625,7 +625,7 @@ Okay, let's commit and deploy again: > git add . > git commit -am 'Add users table.' - [master 8c16c09] Add users table. + [main 8c16c09] Add users table. 4 files changed, 22 insertions(+) create mode 100644 deploy/users.sql create mode 100644 revert/users.sql @@ -804,7 +804,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 b36f48b] Add flips table and userflips view. + [main b36f48b] Add flips table and userflips view. 7 files changed, 43 insertions(+) create mode 100644 deploy/flips.sql create mode 100644 deploy/userflips.sql @@ -845,7 +845,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 84ed9db] Tag the database with v1.0.0-dev1. + [main 84ed9db] Tag the database with v1.0.0-dev1. 1 files changed, 1 insertion(+) > git tag v1.0.0-dev1 -am 'Tag v1.0.0-dev1' @@ -973,14 +973,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. +Good, we've finished this feature. Time to merge back into C
. =head2 Emergency Let's do it: - > git checkout master - Switched to branch 'master' + > git checkout main + Switched to branch 'main' > git pull Updating 84ed9db..31d026c Fast-forward @@ -993,7 +993,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. +Hrm, that's interesting. Looks like someone made some changes to C
. They added list support. Well, let's see what happens when we merge our changes. @@ -1006,38 +1006,38 @@ Oh, a conflict in F. Not too surprising, since both the merged C branch and our C 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 before merging in a branch. What one I do +what's changed in C
before merging in a branch. What one I do is either: =over =item * -Rebase the F branch from master before merging. This "rewinds" the -branch changes, pulls from C, and then replays the changes back on top +Rebase the F branch from main before merging. This "rewinds" the +branch changes, pulls from C
, and then replays the changes back on top of the pulled changes. =item * -Create a patch and apply I to master. This is the sort of thing you +Create a patch and apply I 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 31d026c Merge branch 'lists' That throws out our botched merge. Now let's go back to our branch and rebase -it on C: +it on C
: > 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... @@ -1081,7 +1081,7 @@ Now add the union merge driver to F<.gitattributes> for F 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... @@ -1138,10 +1138,10 @@ worthwhile to keep that change: =head2 Merges Mastered -And now, finally, we can merge into C: +And now, finally, we can merge into C
: - > 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 the 'recursive' strategy. .gitattributes | 1 + @@ -1171,14 +1171,14 @@ And double-check our work: lists [appschema flips] 2018-07-27T16:00:00Z Marge N. O’Vera # Adds table for storing lists. hashtags [flips] 2018-07-27T15:51:16Z Marge N. O’Vera # 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 1c67e0d] Tag the database with v1.0.0-dev2. + [main 1c67e0d] Tag the database with v1.0.0-dev2. 1 files changed, 1 insertion(+) > git tag v1.0.0-dev2 -am 'Tag v1.0.0-dev2' > sqitch bundle --dest-dir flipr-1.0.0-dev2 @@ -1266,8 +1266,8 @@ point of fact, it has copied the files to stand in for the previous instance of the C change, which we can see via C: > git status - On branch master - Your branch is up to date with 'origin/master'. + On branch main + Your branch is up to date with 'origin/main'. Changes not staged for commit: (use "git add ..." to update what will be committed) @@ -1382,7 +1382,7 @@ Excellent. Let's go ahead and commit these changes: > git add . > git commit -m 'Add the twitter column to the userflips view.' - [master c004445] Add the twitter column to the userflips view. + [main c004445] Add the twitter column to the userflips view. 7 files changed, 31 insertions(+), 4 deletions(-) create mode 100644 deploy/userflips@v1.0.0-dev2.sql create mode 100644 revert/userflips@v1.0.0-dev2.sql diff --git a/lib/sqitchtutorial-sqlite.pod b/lib/sqitchtutorial-sqlite.pod index c441c702a..7ff69502e 100644 --- a/lib/sqitchtutorial-sqlite.pod +++ b/lib/sqitchtutorial-sqlite.pod @@ -44,7 +44,7 @@ source code repository. So let's do that with Git: > touch README.md > git add . > git commit -m 'Initialize project, add README.' - [master (root-commit) 253542e] Initialize project, add README. + [main (root-commit) 253542e] Initialize project, add README. 1 file changed, 37 insertions(+) create mode 100644 README.md @@ -127,7 +127,7 @@ Let's commit these changes and start creating the database changes. > git add . > git commit -m 'Initialize Sqitch configuration.' - [master 91e2f0d] Initialize Sqitch configuration. + [main 91e2f0d] Initialize Sqitch configuration. 2 files changed, 19 insertions(+) create mode 100644 sqitch.conf create mode 100644 sqitch.plan @@ -350,7 +350,7 @@ Cool. Let's tell Git to ignore F<*.db> files and then commit it. > echo '*.db' > .gitignore > git add . > git commit -m 'Add users table.' - [master 6725454] Add users table. + [main 6725454] Add users table. 5 files changed, 31 insertions(+) create mode 100644 .gitignore create mode 100644 deploy/users.sql @@ -424,7 +424,7 @@ We'll see the L|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 target and always verify.' - [master 5fb57ec] Set default target and always verify. + [main 5fb57ec] Set default target and always verify. 1 file changed, 8 insertions(+) =head1 Deploy with Dependency @@ -579,7 +579,7 @@ Okay, let's commit and deploy again: > git add . > git commit -am 'Add flips table.' - [master 21cba95] Add flips table. + [main 21cba95] Add flips table. 4 files changed, 30 insertions(+) create mode 100644 deploy/flips.sql create mode 100644 revert/flips.sql @@ -649,7 +649,7 @@ Looks good! Commit it. > git add . > git commit -m 'Add the userflips view.' - [master c74bfb4] Add the userflips view. + [main c74bfb4] Add the userflips view. 4 files changed, 29 insertions(+) create mode 100644 deploy/userflips.sql create mode 100644 revert/userflips.sql @@ -664,7 +664,7 @@ 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 7a479fd] Tag the database with v1.0.0-dev1. + [main 7a479fd] Tag the database with v1.0.0-dev1. 1 file changed, 1 insertion(+) > git tag v1.0.0-dev1 -am 'Tag v1.0.0-dev1' @@ -798,14 +798,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. +Good, we've finished this feature. Time to merge back into C
. =head2 Emergency Let's do it: - > git checkout master - Switched to branch 'master' + > git checkout main + Switched to branch 'main' > git pull Updating 7a479fd..47a4107 Fast-forward @@ -818,7 +818,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. +Hrm, that's interesting. Looks like someone made some changes to C
. They added list support. Well, let's see what happens when we merge our changes. @@ -831,38 +831,38 @@ Oh, a conflict in F. Not too surprising, since both the merged C branch and our C 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 before merging in a branch. What one I do +what's changed in C
before merging in a branch. What one I do is either: =over =item * -Rebase the F branch from master before merging. This "rewinds" the -branch changes, pulls from C, and then replays the changes back on top +Rebase the F branch from main before merging. This "rewinds" the +branch changes, pulls from C
, and then replays the changes back on top of the pulled changes. =item * -Create a patch and apply I to master. This is the sort of thing you +Create a patch and apply I 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 47a4107 Merge branch 'lists' That throws out our botched merge. Now let's go back to our branch and rebase -it on C: +it on C
: > 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... @@ -905,7 +905,7 @@ Now add the union merge driver to F<.gitattributes> for F 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... @@ -959,10 +959,10 @@ worthwhile to keep that change: =head2 Merges Mastered -And now, finally, we can merge into C: +And now, finally, we can merge into C
: - > 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 the 'recursive' strategy. .gitattributes | 1 + @@ -991,14 +991,14 @@ And double-check our work: lists [users] 2013-12-31T19:28:05Z Marge N. O’Vera # Adds table for storing lists. hashtags [flips] 2013-12-31T19:30:13Z Marge N. O’Vera # 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 7abfd9b] Tag the database with v1.0.0-dev2. + [main 7abfd9b] Tag the database with v1.0.0-dev2. 1 file changed, 1 insertion(+) > git tag v1.0.0-dev2 -am 'Tag v1.0.0-dev2' > sqitch bundle --dest-dir flipr-1.0.0-dev2 @@ -1085,8 +1085,8 @@ point of fact, it has copied the files to stand in for the previous instance of the C change, which we can see via C: > git status - # On branch master - # Your branch is ahead of 'origin/master' by 4 commits. + # On branch main + # Your branch is ahead of 'origin/main' by 4 commits. # (use "git push" to publish your local commits) # # Changes not staged for commit: @@ -1203,7 +1203,7 @@ Excellent. Let's go ahead and commit these changes: > git add . > git commit -m 'Add the twitter column to the userflips view.' - [master 3eb96d9] Add the twitter column to the userflips view. + [main 3eb96d9] Add the twitter column to the userflips view. 7 files changed, 40 insertions(+), 4 deletions(-) create mode 100644 deploy/userflips@v1.0.0-dev2.sql create mode 100644 revert/userflips@v1.0.0-dev2.sql diff --git a/lib/sqitchtutorial-vertica.pod b/lib/sqitchtutorial-vertica.pod index 99cbb50c3..b0807a509 100644 --- a/lib/sqitchtutorial-vertica.pod +++ b/lib/sqitchtutorial-vertica.pod @@ -176,7 +176,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 @@ -378,7 +378,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 @@ -455,7 +455,7 @@ We'll see the L|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 @@ -600,7 +600,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 @@ -766,7 +766,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 @@ -808,7 +808,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' @@ -943,14 +943,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. +Good, we've finished this feature. Time to merge back into C
. =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 @@ -963,7 +963,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. +Hrm, that's interesting. Looks like someone made some changes to C
. They added list support. Well, let's see what happens when we merge our changes. @@ -976,38 +976,38 @@ Oh, a conflict in F. Not too surprising, since both the merged C branch and our C 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 before merging in a branch. What one I do +what's changed in C
before merging in a branch. What one I do is either: =over =item * -Rebase the F branch from master before merging. This "rewinds" the -branch changes, pulls from C, and then replays the changes back on top +Rebase the F branch from main before merging. This "rewinds" the +branch changes, pulls from C
, and then replays the changes back on top of the pulled changes. =item * -Create a patch and apply I to master. This is the sort of thing you +Create a patch and apply I 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: +it on C
: > 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... @@ -1051,7 +1051,7 @@ Now add the union merge driver to F<.gitattributes> for F 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... @@ -1110,10 +1110,10 @@ worthwhile to keep that change: =head2 Merges Mastered -And now, finally, we can merge into C: +And now, finally, we can merge into C
: - > 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 + @@ -1143,14 +1143,14 @@ And double-check our work: lists [appschema users] 2014-09-05T17:33:43Z Marge N. O’Vera # Adds table for storing lists. hashtags [appschema flips] 2014-09-05T17:39:53Z Marge N. O’Vera # 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 @@ -1238,7 +1238,7 @@ point of fact, it has copied the files to stand in for the previous instance of the C change, which we can see via C: > git status - # On branch master + # On branch main # Changed but not updated: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) @@ -1353,7 +1353,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 diff --git a/lib/sqitchtutorial.pod b/lib/sqitchtutorial.pod index 9dee237b0..dba34d61e 100644 --- a/lib/sqitchtutorial.pod +++ b/lib/sqitchtutorial.pod @@ -126,7 +126,7 @@ Let's commit these changes and start creating the database changes. > git add . > git commit -am 'Initialize Sqitch configuration.' - [master 85e8d7c] Initialize Sqitch configuration. + [main 85e8d7c] Initialize Sqitch configuration. 2 files changed, 19 insertions(+) create mode 100644 sqitch.conf create mode 100644 sqitch.plan @@ -359,7 +359,7 @@ Cool. Now let's commit it. > git add . > git commit -m 'Add flipr schema.' - [master d812132] Add flipr schema. + [main d812132] Add flipr schema. 4 files changed, 22 insertions(+) create mode 100644 deploy/appschema.sql create mode 100644 revert/appschema.sql @@ -435,7 +435,7 @@ We'll see the L|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 a6267d3] Set default deployment target and always verify. + [main a6267d3] Set default deployment target and always verify. 1 file changed, 8 insertions(+) =head1 Deploy with Dependency @@ -591,7 +591,7 @@ Okay, let's commit and deploy again: > git add . > git commit -am 'Add users table.' - [master d58ea2f] Add users table. + [main d58ea2f] Add users table. 4 files changed, 31 insertions(+) create mode 100644 deploy/users.sql create mode 100644 revert/users.sql @@ -765,7 +765,7 @@ the last deployed change. Looks good. Let's do the commit and re-deploy dance: > git add . > git commit -m 'Add `insert_user()` and `change_pass()`.' - [master c9b4d68] Add `insert_user()` and `change_pass()`. + [main c9b4d68] Add `insert_user()` and `change_pass()`. 7 files changed, 65 insertions(+) create mode 100644 deploy/change_pass.sql create mode 100644 deploy/insert_user.sql @@ -807,7 +807,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 "change_pass" with @v1.0.0-dev1 > git commit -am 'Tag the database with v1.0.0-dev1.' - [master 0acef3e] Tag the database with v1.0.0-dev1. + [main 0acef3e] Tag the database with v1.0.0-dev1. 1 file changed, 1 insertion(+) > git tag v1.0.0-dev1 -am 'Tag v1.0.0-dev1' @@ -1065,14 +1065,14 @@ should end up looking something like this: # Nothing to deploy (up-to-date) -Good, we've finished this feature. Time to merge back into C. +Good, we've finished this feature. Time to merge back into C
. =head2 Emergency Let's do it: - > git checkout master - Switched to branch 'master' + > git checkout main + Switched to branch 'main' > git pull Updating 0acef3e..d4cbd7d Fast-forward @@ -1097,7 +1097,7 @@ Let's do it: create mode 100644 verify/insert_list.sql create mode 100644 verify/lists.sql -Hrm, that's interesting. Looks like someone made some changes to C. +Hrm, that's interesting. Looks like someone made some changes to C
. They added list support. Well, let's see what happens when we merge our changes. @@ -1110,38 +1110,38 @@ Oh, a conflict in F. Not too surprising, since both the merged C branch and our C 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 before merging in a branch. What one I do +what's changed in C
before merging in a branch. What one I do is either: =over =item * -Rebase the F branch from master before merging. This "rewinds" the -branch changes, pulls from C, and then replays the changes back on top +Rebase the F branch from main before merging. This "rewinds" the +branch changes, pulls from C
, and then replays the changes back on top of the pulled changes. =item * -Create a patch and apply I to master. This is the sort of thing you +Create a patch and apply I 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 ff60b9b Merge branch 'lists' That throws out our botched merge. Now let's go back to our branch and rebase -it on C: +it on C
: > git checkout flips Switched to branch 'flips' - > git rebase master + > git rebase main First, rewinding head to replay your work on top of it... Applying: Add flips table. Using index info to reconstruct a base tree... @@ -1184,7 +1184,7 @@ Now add the union merge driver to F<.gitattributes> for F 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 flips table. Using index info to reconstruct a base tree... @@ -1260,10 +1260,10 @@ worthwhile to keep that change: =head2 Merges Mastered -And now, finally, we can merge into C: +And now, finally, we can merge into C
: - > git checkout master - Switched to branch 'master' + > git checkout main + Switched to branch 'main' > git merge --no-ff flips Merge made by the 'recursive' strategy. .gitattributes | 1 + @@ -1309,14 +1309,14 @@ And double-check our work: insert_flip [flips appschema users] 2013-12-31T00:35:59Z Marge N. O’Vera # Creates a function to insert a flip. delete_flip [flips appschema users] 2013-12-31T00:36:34Z Marge N. O’Vera # Creates a function to delete a flip. -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 "flips" 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 "delete_flip" with @v1.0.0-dev2 > git commit -am 'Tag the database with v1.0.0-dev2.' - [master 230603b] Tag the database with v1.0.0-dev2. + [main 230603b] Tag the database with v1.0.0-dev2. 1 file changed, 1 insertion(+) > git tag v1.0.0-dev2 -am 'Tag v1.0.0-dev2' > sqitch bundle --dest-dir flipr-1.0.0-dev2 @@ -1454,7 +1454,7 @@ point of fact, it has copied the files to stand in for the previous instance of the C change, which we can see via C: > git status - # On branch master + # On branch main # Changes not staged for commit: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) @@ -1636,7 +1636,7 @@ Excellent. Let's go ahead and commit these changes: > git add . > git commit -m 'Use pgcrypto to encrypt passwords.' - [master 4257ae6] Use pgcrypto to encrypt passwords. + [main 4257ae6] Use pgcrypto to encrypt passwords. 13 files changed, 107 insertions(+), 9 deletions(-) create mode 100644 deploy/change_pass@v1.0.0-dev2.sql create mode 100644 deploy/insert_user@v1.0.0-dev2.sql diff --git a/t/checkout.t b/t/checkout.t index 0900a4a60..18c0edb25 100644 --- a/t/checkout.t +++ b/t/checkout.t @@ -507,13 +507,13 @@ foo 2012-07-16T17:25:07Z Barack Obama bar 2012-07-16T17:25:07Z Barack Obama }; -throws_ok { $checkout->execute('master') } 'App::Sqitch::X', +throws_ok { $checkout->execute('main') } 'App::Sqitch::X', 'Should get an error for plans without a common change'; is $@->ident, 'checkout', 'The no common change error ident should be "checkout"'; is $@->message, __x( 'Branch {branch} has no changes in common with current branch {current}', - branch => 'master', + branch => 'main', current => $probed, ), 'The no common change error message should be correct'; @@ -550,13 +550,13 @@ isa_ok $checkout = $CLASS->new( revert_variables => { hey => 'there' }, ), $CLASS, 'Object with to and variables'; -ok $checkout->execute('master'), 'Checkout master'; +ok $checkout->execute('main'), 'Checkout main'; is_deeply \@probe_args, [$client, qw(rev-parse --abbrev-ref HEAD)], 'The proper args should again have been passed to rev-parse'; -is_deeply \@capture_args, [$client, 'show', 'master:' . $checkout->default_target->plan_file ], +is_deeply \@capture_args, [$client, 'show', 'main:' . $checkout->default_target->plan_file ], - 'Should have requested the plan file contents as of master'; -is_deeply \@run_args, [$client, qw(checkout master)], 'Should have checked out other branch'; + 'Should have requested the plan file contents as of main'; +is_deeply \@run_args, [$client, qw(checkout main)], 'Should have checked out other branch'; is_deeply +MockOutput->get_warn, [], 'Should have no warnings'; is_deeply +MockOutput->get_info, [[__x( @@ -586,7 +586,7 @@ is_deeply { @{ $vars[1] } }, { foo => 'bar', one => 1 }, # Try passing a target. @vars = (); -ok $checkout->execute('master', 'db:sqlite:foo'), 'Checkout master with target'; +ok $checkout->execute('main', 'db:sqlite:foo'), 'Checkout main with target'; is $target->name, 'db:sqlite:foo', 'Target should be passed to engine'; is_deeply +MockOutput->get_warn, [], 'Should have no warnings'; @@ -604,7 +604,7 @@ isa_ok $checkout = $CLASS->new( $mock_engine->mock(revert => sub { hurl { ident => 'revert', message => 'foo', exitval => 1 } }); @dep_args = @rev_args = @vars = (); -ok $checkout->execute('master'), 'Checkout master again'; +ok $checkout->execute('main'), 'Checkout main again'; is $target->name, 'db:sqlite:hello', 'Target should be passed to engine'; is_deeply +MockOutput->get_warn, [], 'Should have no warnings'; @@ -622,7 +622,7 @@ is_deeply { @{ $vars[1] } }, { foo => 'bar', one => 1 }, 'The deploy vars should again have been next'; # Should get a warning for two targets. -ok $checkout->execute('master', 'db:sqlite:'), 'Checkout master again with target'; +ok $checkout->execute('main', 'db:sqlite:'), 'Checkout main again with target'; is $target->name, 'db:sqlite:hello', 'Target should be passed to engine'; is_deeply +MockOutput->get_warn, [[__x( 'Too many targets specified; connecting to {target}', @@ -630,7 +630,7 @@ is_deeply +MockOutput->get_warn, [[__x( )]], 'Should have warning about two targets'; # Make sure we get an exception for unknown args. -throws_ok { $checkout->execute(qw(master greg)) } 'App::Sqitch::X', +throws_ok { $checkout->execute(qw(main greg)) } 'App::Sqitch::X', 'Should get an exception for unknown arg'; is $@->ident, 'checkout', 'Unknow arg ident should be "checkout"'; is $@->message, __nx( @@ -640,7 +640,7 @@ is $@->message, __nx( arg => 'greg', ), 'Should get an exeption for two unknown arg'; -throws_ok { $checkout->execute(qw(master greg widgets)) } 'App::Sqitch::X', +throws_ok { $checkout->execute(qw(main greg widgets)) } 'App::Sqitch::X', 'Should get an exception for unknown args'; is $@->ident, 'checkout', 'Unknow args ident should be "checkout"'; is $@->message, __nx( @@ -657,7 +657,7 @@ for my $spec ( [ unknown => bless { } => __PACKAGE__ ], ) { $mock_engine->mock(revert => sub { die $spec->[1] }); - throws_ok { $checkout->execute('master') } ref $spec->[1], + throws_ok { $checkout->execute('main') } ref $spec->[1], "Should rethrow $spec->[0] exception"; }