git-lint 1.2.0 → 2.2.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: ad69b383eac0eec9f092da4cdfb914481b634357ddd4231b35990b7d5d3c7f58
-  data.tar.gz: 42f72eda7f6519e4d86329691853e751234e4c6cf044dd02538df018762ad29c
+  metadata.gz: 1a0ccd4d14bc5a75b14ae5a825f5eec453a560bc3e6df2bc959bbcb90f626794
+  data.tar.gz: 5f64925793493c9cde59a4828666137ba6a5203f664d5b97ce994552b38fcb42
 SHA512:
-  metadata.gz: c68bb8ab97984d8dff32760849a9c09826810a390a7269debba43415f24d7b6141561d24a3537f5c080a448bcecefb4e4c8fa1435f03ef2c2062028e8063122c
-  data.tar.gz: 546178cb0708443ec30e0740629653482eb01e4dca0120fe2ae50116f3e5b07066daf7668871bb71f34b10d1e8775dd44518915b66f495d24d4a1c3acd23ee9e
+  metadata.gz: b295196574a134f2ae5a3989c71d7023998eaf96476055a8c511a3f5d684fbaf1d9456fe887389042d4f8a88fb0d7bce0ea8e1a5663c490c1cf7756b9d6384c8
+  data.tar.gz: 542818d4e2dced990b4231b53160e6c59272c1db908e309a10566210be26eeddb6213ec1f6581c75b078f6d8581e0b4f85827efe03d0f93ce9a216a8133c94a8

data/README.adoc

@@ -8,31 +8,29 @@
 
 [link=http://badge.fury.io/rb/git-lint]
 image::https://badge.fury.io/rb/git-lint.svg[Gem Version]
+[link=https://www.alchemists.io/projects/code_quality]
+image::https://img.shields.io/badge/code_style-alchemists-brightgreen.svg[Alchemists Style Guide]
 [link=https://circleci.com/gh/bkuhlmann/git-lint]
 image::https://circleci.com/gh/bkuhlmann/git-lint.svg?style=svg[Circle CI Status]
 
 [link=https://travis-ci.org/bkuhlmann/git-lint]
-image::https://travis-ci.org/bkuhlmann/git-lint.svg?branch=master[Travis CI Status]
+image::https://travis-ci.org/bkuhlmann/git-lint.svg?branch=main[Travis CI Status]
 [link=https://app.netlify.com/sites/git-lint/deploys]
 image::https://api.netlify.com/api/v1/badges/7e23b422-3412-4e7f-b654-65c0417a0b1f/deploy-status[Netlify CI Status]
 
 A command line interface for linting Git commits. Ensures you maintain a clean, easy to read,
 debuggable, and maintainable project history.
 
-*Git Lint is the official port of the original Git Cop project that avoids references to violence or
-violent terminology that might make anyone feel unwelcome. The name change was necessary in order to
-better support the link:https://blacklivesmatter.com[Black Lives Matter] and
-link:https://8cantwait.org[Defund Police] movements.*
-
 toc::[]
 
 == Features
 
 * Enforces a {git_rebase_workflow_link}.
 * Enforces a clean and consistent Git commit history.
+* Supports Git default branch configuration.
 * Provides a customizable suite of analyzers.
 * Provides Git Hook support for local use.
-* Provides Continuous Integration (CI) build server support.
+* Provides Continuous Integration (CI) support.
 
 == Screencasts
 
@@ -69,9 +67,9 @@ git-lint -v, [--version]       # Show gem version.
 To check if your Git commit history is clean, run: `git-lint --analyze`. It will exit with a failure
 if at least one issue with error severity is detected.
 
-This gem does not check commits on `master`. This is intentional as you would, generally, not want
-to rewrite or fix commits on `master`. This gem is best used on feature branches as it automatically
-detects all commits made since `master` on the feature branch.
+This gem does not check commits on your default branch (i.e. `main`). This is intentional as you
+would, generally, not want to rewrite or fix commits on the `main` branch. This gem is best used on
+feature branches as it automatically detects all commits made since creation of the feature branch.
 
 Here is an example workflow, using gem defaults with issues detected:
 
@@ -113,6 +111,21 @@ Now, when running `bundle exec rake -T`, you'll see `git_lint` included in the l
 
 If you need a concrete example, check out the link:Rakefile[Rakefile] of this project for details.
 
+=== Default Branch
+
+Your default branch configuration is respected no matter if it is set globally or locally. If the
+default branch is _not set_ then Git Lint will fall back to `master` for backwards compatibility.
+When the next major version is released, the default branch fallback will change from `master` to
+`main`. You can set your default branch at any time by running the following from the command line:
+
+[source,bash]
+----
+git config --add init.defaultBranch main
+----
+
+💡 When setting your default branch, ensure you use a consistent Git configuration across all of
+your environments.
+
 === Configuration
 
 This gem can be configured via a global configuration:
@@ -291,7 +304,7 @@ maintenance costs for you. To configure global Git Hooks, add the following to y
 ....
 
 Then you can customize Git Hooks for all of your projects.
-link:https://github.com/bkuhlmann/dotfiles/tree/master/home_files/.config/git/hooks[Check out these
+link:https://github.com/bkuhlmann/dotfiles/tree/main/home_files/.config/git/hooks[Check out these
 examples].
 
 If a global configuration is not desired, you can add Git Hooks at a per project level by editing
@@ -376,7 +389,7 @@ have a build server that is not listed, please log an issue or provide an implem
 support.
 
 Calculation of commits is done by reviewing all commits made on the feature branch since branching
-from `master`.
+from `main`.
 
 ==== link:https://circleci.com[Circle CI]
 
@@ -868,7 +881,7 @@ worth considering:
   blindly combine multiple commit messages without editing them into a single, coherent message._
 * Use `git rebase --interactive` when cleaning up commit history, order, messages, etc. This should
   be done prior to submitting a code review or when code review feedback has been addressed and
-  you are ready to rebase onto `master`.
+  you are ready to rebase onto `main`.
 * Use `git push --force-with-lease` instead of `git push --force` when pushing changes after an
   interactive rebasing session.
 * Avoid checking in development-specific configuration files (add to `.gitignore` instead).
@@ -913,19 +926,24 @@ configuration disabled.
 * Use small, atomic commits:
 ** Easier to review and provide feedback.
 ** Easier to review implementation and corresponding tests.
-** Easier to document with detailed subject messages (especially when grouped together in a pull
-   request).
+** Easier to document with detailed subjects (especially when grouped together in a pull request).
 ** Easier to reword, edit, squash, fix, or drop when interactively rebasing.
 ** Easier to combine together versus tearing apart a larger commit into smaller commits.
 * Use logically ordered commits:
 ** Each commit should tell a story and be a logical building block to the next commit.
+** Each commit should, ideally, be the implementation plus corresponding test. Avoid committing
+   changes that are a jumble of mixed ideas as they are hard to decipher and a huge insult not only
+   to the reviewer but your future self.
 ** Each commit, when reviewed in order, should be able to explain _how_ the feature or bug fix was
    completed and implemented properly.
+* Keep refactored code separate from behavioral changes. This makes the review process easier
+  because you don't have to sift through all the line and format changes to figure out what is new
+  or changed.
 
 === Branches
 
 * Use feature branches for new work.
-* Maintain branches by rebasing upon `master` on a regular basis.
+* Maintain branches by rebasing upon `main` on a regular basis.
 
 === Tags
 
@@ -947,15 +965,18 @@ configuration disabled.
 * Use hooks globally rather than locally per project. Doing this applies the same functionality
   across all projects automatically, reduces maintenance per project, and provides consistency
   across all projects. This can best be managed via your
-  link:https://github.com/bkuhlmann/dotfiles/tree/master/home_files/.config/git/hooks[Dotfiles].
+  link:https://github.com/bkuhlmann/dotfiles/tree/main/home_files/.config/git/hooks[Dotfiles].
 * Avoid forcing global or local project hooks as a team-wide mandate. Hooks are a personal tool much
   like editors or other tools one choose to do their work. For team consistency, use a continuous
   integration build server instead.
 
 === Code Reviews
 
-There are two objectives each code review should achieve:
+There are three main objectives each code review should achieve:
 
+. *Joy* - The experience of working with you, receiving feedback, giving feedback, and demonstrating
+   a level of care influences others and encourages a collaborative environment that is fun to work
+   in. Use this time to build and reinforce trust amongst your fellow colleagues.
 . *Quality*: Ensures changes are of highest quality that adhere to team standards while enhancing
    the customer experience and not disrupting their workflow.
 . *Education*: Provides a chance for everyone on the team to learn more about the architecture,
@@ -965,13 +986,22 @@ There are two objectives each code review should achieve:
 In addition to the objectives above, the following guidelines are worth following:
 
 * Keep code reviews short and easy to review:
+** Review your own code first before submitting to others. By ensuring your are confident in the
+   overall implementation and the commits in terms of commit messages and implementation details,
+   you'll encourage higher quality feedback and show appreciation for the reviewer's time.
 ** Provide a high level overview that answers _why_ the code review is necessary.
-** Provide a link to the issue/task that prompted the code review (if any).
+** Provide a link to the issue that prompted the code review (if any) and any additional details
+   worth highlighting to guide the reviewer through the process.
 ** Provide screenshots/screencasts if possible.
-** Ensure commits within the code review are related to the purpose of the code review.
-** Prefer code reviews at about 250 lines in order to keep the quality of the code review and defect
-   detection high.
-** Avoid working on a large issue without getting feedback first in order to not overwhelm/surprise
+** Provide any ancillary notes or points of interest worth highlighting for the reviewer.
+** Ensure commits within the code review are related to the purpose of the code review and avoid
+   mixing in changes that are ancillary to the primary objective of the code view. If you do have
+   changes outside of the scope of the current code review, open those changes up as a separate code
+   review instead.
+** Prefer code reviews at about 300 lines in order to keep the quality of the code review and defect
+   detection high. This also shows you value the reviewers time and attention away from their own
+   work.
+** Avoid working on a large issues without first getting feedback in order to not overwhelm/surprise
    the maintainers. More discussion up front will help ensure your work has a faster chance of
    acceptance.
 * Review and rebase code reviews quickly:
@@ -1002,25 +1032,30 @@ In addition to the objectives above, the following guidelines are worth followin
     implementation. This is _blocking_ and requires immediate correction. The reviewer should
     provide a suggested solution and/or links to patterns, articles, etc. that might help the author
     fix the implementation. Pairing is encouraged if feedback is vast and/or complex.
-** 🔒 (`:lock:`) - Signifies a security violation that would damage us and/or our customers. This is
-   _blocking_ feedback and must be addressed immediately.
+** 🔓 (`:unlock:`) - Signifies a security violation that would damage us and/or our customers. This
+   is _blocking_ feedback and must be addressed immediately.
 ** 💡 (`:bulb:`) - Indicates a helpful tip or trick for improving the code. This can be
     _blocking_ or _non-blocking_ feedback and is left up to the author to decide. Generally, it is a
     good idea to address and resolve the feedback.
 ** 🙇 (`:bow:`) - Indicates thankfulness of the feedback received. This is _non-blocking_ and
     always meant as a response to helpful feedback.
 ** ✅ (`:white_check_mark:`) - Signifies code review approval. The author can
-    rebase onto `master` and delete the feature branch at this point.
+    rebase onto `main` and delete the feature branch at this point.
+* Use all feedback as a chance to learn, teach, strenghen the bond of trust between you and your
+  fellow colleagues, and avoid being cut by
+  link:https://fs.blog/2017/04/mental-model-hanlons-razor[Hanlon's Razor].
+* Use automation to ensure code reviews are consistent, of high quality, and swift to resolve. Each
+  code review can be an opportunity to identify and automate the process further.
 * Use face-to-face communication if a code review's written discussion gets lengthy/noisy.
-* Create new tasks/actions if additional features are discovered during a code review to avoid
-  delaying code review acceptance. Return to the code review once tasks have been logged.
-* The author, not the reviewer, should rebase the feature branch onto `master` upon approval.
-* Avoid reviewing your own code review before rebasing onto `master`. Have another pair of eyes
+* Create follow-up actions if additional features are discovered during a code review to avoid
+  delaying code review acceptance. Return to the code review once the new actions have been logged.
+* The author, not the reviewer, should rebase the feature branch onto `main` upon approval.
+* Avoid reviewing your own code review before rebasing onto `main`. Have another pair of eyes
   review your code first.
-* Ensure the following criteria is met before rebasing your feature branch to `master`:
+* Ensure the following criteria is met before rebasing your feature branch to `main`:
 ** Ensure all `fixup!` and `squash!` commits are interactively rebased. _Avoid rebasing these onto
-   the `master` branch!_
-** Ensure your feature branch is rebased upon `master`.
+   the `main` branch!_
+** Ensure your feature branch is rebased upon `main`.
 ** Ensure all tests and code quality checks are passing.
 ** Ensure the feature branch is deleted after being successfully rebased.
 
@@ -1032,12 +1067,12 @@ and editing your merge options for code reviews as follows:
 
 image::https://www.alchemists.io/images/projects/git-lint/screenshots/github-settings-options.png[GitHub Merge Options]
 
-In addition to the above, you'll want to add _branch_ protection rules for your `master` branch. To
+In addition to the above, you'll want to add _branch_ protection rules for your `main` branch. To
 do this, follow these steps:
 
 . Visit your branch settings (i.e. `https://github.com/<username>/<project>/settings/branches`).
 . Click the _Add rule_ button.
-. For _branch name pattern_, enter: `master`.
+. For _branch name pattern_, enter: `main`.
 . Check _Require pull request reviews before merging_.
 . Set _Required approving reviews_ to `2` as a minimum.
 . Check _Dismiss stale pull request approvals when new commits are pushed_.

data/lib/git/lint.rb

@@ -1,7 +1,7 @@
 # frozen_string_literal: true
 
+require "git_plus"
 require "git/lint/identity"
-require "git/kit/repo"
 require "git/lint/refinements/strings"
 require "git/lint/errors/base"
 require "git/lint/errors/severity"
@@ -11,8 +11,6 @@ require "git/lint/validators/email"
 require "git/lint/validators/name"
 require "git/lint/validators/capitalization"
 require "git/lint/parsers/trailers/collaborator"
-require "git/lint/commits/saved"
-require "git/lint/commits/unsaved"
 require "git/lint/branches/environments/local"
 require "git/lint/branches/environments/circle_ci"
 require "git/lint/branches/environments/git_hub_action"

data/lib/git/lint/analyzers/abstract.rb

@@ -91,10 +91,10 @@ module Git
           end
         end
 
-        def affected_commit_trailer_lines
-          commit.trailer_lines
+        def affected_commit_trailers
+          commit.trailers
                 .each.with_object([])
-                .with_index(commit.trailer_index) do |(line, lines), index|
+                .with_index(commit.trailers_index) do |(line, lines), index|
                   yield if block_given?
                   lines << self.class.build_issue_line(index, line) if invalid_line? line
                 end

data/lib/git/lint/analyzers/commit_author_name.rb

@@ -32,7 +32,7 @@ module Git
         attr_reader :validator
 
         def minimum
-          settings.fetch :minimum
+          settings.fetch __method__
         end
       end
     end

data/lib/git/lint/analyzers/commit_body_leading_line.rb

@@ -12,12 +12,12 @@ module Git
         end
 
         def valid?
-          raw_body = commit.raw_body
-          subject, body = raw_body.split "\n", 2
+          message = commit.message
+          subject, body = message.split "\n", 2
 
           return true if !String(subject).empty? && String(body).strip.empty?
 
-          raw_body.match?(/\A.+(\n\n|\#).+/m)
+          message.match?(/\A.+(\n\n|\#).+/m)
         end
 
         def issue

data/lib/git/lint/analyzers/commit_subject_prefix.rb

@@ -34,7 +34,7 @@ module Git
         private
 
         def fixup_or_squash?
-          commit.is_a?(Git::Lint::Commits::Unsaved) && (commit.fixup? || commit.squash?)
+          commit.fixup? || commit.squash?
         end
       end
     end

data/lib/git/lint/analyzers/commit_trailer_collaborator_capitalization.rb

@@ -23,7 +23,7 @@ module Git
         # rubocop:enable Metrics/ParameterLists
 
         def valid?
-          affected_commit_trailer_lines.empty?
+          affected_commit_trailers.empty?
         end
 
         def issue
@@ -31,7 +31,7 @@ module Git
 
           {
             hint: "Name must be capitalized.",
-            lines: affected_commit_trailer_lines
+            lines: affected_commit_trailers
           }
         end
 

data/lib/git/lint/analyzers/commit_trailer_collaborator_duplication.rb

@@ -20,7 +20,7 @@ module Git
         end
 
         def valid?
-          affected_commit_trailer_lines.empty?
+          affected_commit_trailers.empty?
         end
 
         def issue
@@ -28,7 +28,7 @@ module Git
 
           {
             hint: "Avoid duplication.",
-            lines: affected_commit_trailer_lines
+            lines: affected_commit_trailers
           }
         end
 
@@ -47,7 +47,7 @@ module Git
           zeros = Hash.new { |new_hash, missing_key| new_hash[missing_key] = 0 }
 
           zeros.tap do |collection|
-            commit.trailer_lines.each { |line| collection[line] += 1 if parser.new(line).match? }
+            commit.trailers.each { |line| collection[line] += 1 if parser.new(line).match? }
           end
         end
       end

data/lib/git/lint/analyzers/commit_trailer_collaborator_email.rb

@@ -24,7 +24,7 @@ module Git
         # rubocop:enable Metrics/ParameterLists
 
         def valid?
-          affected_commit_trailer_lines.empty?
+          affected_commit_trailers.empty?
         end
 
         def issue
@@ -32,7 +32,7 @@ module Git
 
           {
             hint: %(Email must follow name and use format: "<name@server.domain>".),
-            lines: affected_commit_trailer_lines
+            lines: affected_commit_trailers
           }
         end
 

data/lib/git/lint/analyzers/commit_trailer_collaborator_key.rb

@@ -20,7 +20,7 @@ module Git
         end
 
         def valid?
-          affected_commit_trailer_lines.empty?
+          affected_commit_trailers.empty?
         end
 
         def issue
@@ -28,7 +28,7 @@ module Git
 
           {
             hint: "Use format: #{filter_list.to_hint}.",
-            lines: affected_commit_trailer_lines
+            lines: affected_commit_trailers
           }
         end
 

data/lib/git/lint/analyzers/commit_trailer_collaborator_name.rb

@@ -25,7 +25,7 @@ module Git
         # rubocop:enable Metrics/ParameterLists
 
         def valid?
-          affected_commit_trailer_lines.empty?
+          affected_commit_trailers.empty?
         end
 
         def issue
@@ -33,7 +33,7 @@ module Git
 
           {
             hint: "Name must follow key and consist of #{minimum} parts (minimum).",
-            lines: affected_commit_trailer_lines
+            lines: affected_commit_trailers
           }
         end
 

data/lib/git/lint/branches/environments/circle_ci.rb

@@ -6,21 +6,21 @@ module Git
       module Environments
         # Provides Circle CI build environment feature branch information.
         class CircleCI
-          def initialize repo: Git::Kit::Repo.new
-            @repo = repo
+          def initialize repository: GitPlus::Repository.new
+            @repository = repository
           end
 
           def name
-            "origin/#{repo.branch_name}"
+            "origin/#{repository.branch_name}"
           end
 
-          def shas
-            repo.shas start: "origin/master", finish: name
+          def commits
+            repository.commits "origin/#{repository.branch_default}..#{name}"
           end
 
           private
 
-          attr_reader :repo
+          attr_reader :repository
         end
       end
     end

data/lib/git/lint/branches/environments/git_hub_action.rb

@@ -6,21 +6,21 @@ module Git
       module Environments
         # Provides GitHub Action build environment feature branch information.
         class GitHubAction
-          def initialize repo: Git::Kit::Repo.new
-            @repo = repo
+          def initialize repository: GitPlus::Repository.new
+            @repository = repository
           end
 
           def name
-            "origin/#{repo.branch_name}"
+            "origin/#{repository.branch_name}"
           end
 
-          def shas
-            repo.shas start: "origin/master", finish: name
+          def commits
+            repository.commits "origin/#{repository.branch_default}..#{name}"
           end
 
           private
 
-          attr_reader :repo
+          attr_reader :repository
         end
       end
     end