git-lint 1.3.0 → 2.2.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: fee007aea853b3ee86b0bbd66dc27b0debb3bdd69227cd693f989e470fdbaf25
-  data.tar.gz: a63392c0e6cf3dfa6cbd06bb361521327ea7326228c4b83163eba3d41435d762
+  metadata.gz: 432f1e46b50a5ae86dc268318ea2a2cf720e68d57a00cbdc274d50379bbee24f
+  data.tar.gz: 5ca784153ebd07153c70b4e7452a7ef0e141b32789e5d4f1c0fb95d861d698b2
 SHA512:
-  metadata.gz: 7c53d8b1657d48661796f82dba61954eb1f3ed17dac90d602ccd89147cae44efd3b9a1ed9b07bad5b5b53f61800f376f4f08053c4bbb76a3d287f2546e03536c
-  data.tar.gz: a5b6afdb80917dc75684878b0cd7679a240e76f6a8f17dc31d0b859aaeeba7d04e7d2bfe8ffe7175910c69f939391d0f0cf4001d5f0730b3af2cb7e31f9e69e5
+  metadata.gz: 9f53f339560363704e3f35560d3ee5dc6b43012c9eadbf088cd580ddbd0738f6933a16f963406eeb882d2f0d951b95894f7c25a581582c3058074879ab12e3ba
+  data.tar.gz: b5cbe2dbe299a0f3690d64ceb6b2df00074d2112bdbb7bf93c031268705289db782118f19411f0083b592407fc071c84a5311deab01d6afd13e17592a03cb4de

data/README.adoc

@@ -14,27 +14,23 @@ image::https://img.shields.io/badge/code_style-alchemists-brightgreen.svg[Alchem
 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
 
@@ -71,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:
 
@@ -115,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:
@@ -293,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
@@ -378,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]
 
@@ -736,9 +747,12 @@ Ensures the commit subject uses consistent prefixes that explain _what_ is being
 * *Updated* - Identifies what was updated. The commit should be as small as possible and _not add
   or fix_ existing behavior. This can sometimes be a grey area but is typically reserved for updates
   to documentation, code comments, dependencies, etc.
-* *Refactored* - Identifies what was refactored. The commit should be as small as possible and only
-  improve existing functionality while avoiding changes in behavior (especially to public API
-  that might effect downstream dependencies). Refactored code should never break existing specs.
+* *Refactored* - Identifies what was refactored.
+  link:https://thoughtbot.com/blog/lets-not-misuse-refactoring[_Refactoring is for changing code
+  structure without changing observable behavior_]. The commit should be as small as possible and
+  not mix multiple kinds of changes at once. Refactored code should never break existing
+  implementation behavior or corresponding specs because, if that happens, then one of the other
+  four prefixes is what you want to use instead.
 
 In practice, using a prefix other than what has been detailed above to explain _what_ is being
 committed is never needed. These prefixes are not only short and easy to remember but also have the
@@ -870,7 +884,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).
@@ -915,23 +929,28 @@ 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
 
-* Use tags to denote milestones/releases:
+* Use tags to denote link:https://www.alchemists.io/projects/milestoner[milestones]/releases:
 ** Makes it easier to record milestones and capture associated release notes.
 ** Makes it easier to compare differences between versions.
 ** Provides a starting point for debugging production issues (if any).
@@ -949,114 +968,15 @@ 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:
-
-. *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,
-   product/service, and how each member of the team implements a solution. This is your chance to
-   ask questions and learn how to be a better engineer so take advantage of it.
-
-In addition to the objectives above, the following guidelines are worth following:
-
-* Keep code reviews short and easy to review:
-** 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 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
-   the maintainers. More discussion up front will help ensure your work has a faster chance of
-   acceptance.
-* Review and rebase code reviews quickly:
-** Maintain a consistent but reasonable pace -- Review morning, noon, and night.
-** Avoid letting code reviews linger more than a day. Otherwise, you risk hampering moral and
-   diminishing the productivity of the team.
-* Use emojis, with a format of `<emoji> <feedback>`, to identify the kinds of feedback used during
-  the review process:
-** 🍵 (`:tea:`) - Signifies you are starting the code review. This is _non-blocking_ and
-    informational. Useful when reading over a code review with a large number of commits, complex
-    code, requires additional testing by the reviewer, etc.
-** ⭐️ (`:star:`) - Signifies code that is liked, favorited, remarkable, etc. This feedback is
-    _non-blocking_ and is always meant to be positive/uplifting.
-** ℹ️ (`:information_source:`) - Signifies informational feedback that is
-    _non-blocking_. Can also be used to let one know you are done reviewing but haven't approved yet
-    (due to feedback that needs addressing), rebasing a code review and then merging, waiting for a
-    blocking code review to be resolved, status updates to the code review, etc.
-** 💭 (`:thought_balloon:`) - Signifies inquisitive intent that is _non-blocking_.
-    Useful when asking questions and/or probing deeper into implementation details to learn more.
-** 🔤 (`:abc:`) - Signifies detection of a misspelling with suggested correction. This is
-    _blocking_ feedback that is easy to correct.
-** 🎨 (`:art:`) - Signifies an issue with code style and/or code quality. This can be _blocking_
-    or _non-blocking_ feedback. It is up to the discretion of the author on how to address the
-    feedback but encouraged that the feedback is incorporated or at least discussed. Generally,
-    these situations are automatically detected via code linters but there are occasions where
-    there is ambiguity in which linters can't catch.
-** 🏛 (`:classical_building:`) - Signifies an issue with the architecture of the
-    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.
-** 💡 (`: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.
-* 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
-  review your code first.
-* Ensure the following criteria is met before rebasing your feature branch to `master`:
-** Ensure all `fixup!` and `squash!` commits are interactively rebased. _Avoid rebasing these onto
-   the `master` branch!_
-** Ensure your feature branch is rebased upon `master`.
-** Ensure all tests and code quality checks are passing.
-** Ensure the feature branch is deleted after being successfully rebased.
-
-=== GitHub
-
-When using GitHub, enforce a rebase workflow for all of your GitHub projects (_highly recommended_).
-You can do this via your project options (i.e. `https://github.com/<username/<project>/settings`)
-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
-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`.
-. 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_.
-. Check _Require review from Code Owners_.
-. Check _Require status checks to pass before merging_.
-. Check _Require branches to be up to date before merging_.
-. Check _Require signed commits_.
-. Check _Require linear history_ (pairs well with the merge options mentioned above).
-. Check _Include administrators_.
-. Uncheck _Allow force pushes_.
-. Uncheck _Allow deletions_.
-
-With the above applied, you should have the following result:
-
-image::https://www.alchemists.io/images/projects/git-lint/screenshots/github-settings-branch_protections.png[GitHub Branch Protections]
-
-Applying the above changes will help maintain a clean Git history.
+For an in depth look at how to conduct code reviews, please read my
+link:https://www.alchemists.io/articles/code_reviews[article] on this subject to learn more.
 
 == Development
 

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