git-lint 1.3.0 → 1.4.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: fee007aea853b3ee86b0bbd66dc27b0debb3bdd69227cd693f989e470fdbaf25
-  data.tar.gz: a63392c0e6cf3dfa6cbd06bb361521327ea7326228c4b83163eba3d41435d762
+  metadata.gz: 6cb65f70f2b6923d02f717470a175b4a12f4aadf8f138ce2687ebdd73be3d300
+  data.tar.gz: 69a3dae72502594bd98c0397c29431bbfa4479fc6b5cebe8e76ce4149505085d
 SHA512:
-  metadata.gz: 7c53d8b1657d48661796f82dba61954eb1f3ed17dac90d602ccd89147cae44efd3b9a1ed9b07bad5b5b53f61800f376f4f08053c4bbb76a3d287f2546e03536c
-  data.tar.gz: a5b6afdb80917dc75684878b0cd7679a240e76f6a8f17dc31d0b859aaeeba7d04e7d2bfe8ffe7175910c69f939391d0f0cf4001d5f0730b3af2cb7e31f9e69e5
+  metadata.gz: 516084aa71ca86ec7fb5b4acbbc5eac343d6c4d44cc01ea8742c7882a3c203bafb9108fa788f0a00c4874bca40e810080b9b84d5d3ae583585e6efdef8166eb2
+  data.tar.gz: 1dbdb7ecf79311784ef01ede90695df2093fbd7d43b918e39d6bb596843bbaa87d6df59a8f57a901a8fdfb4cc5a935d92d7ad69bdde5f24ba0859f8d5efdb92f

data.tar.gz.sig

@@ -1,3 +1,3 @@
-2i�?��pv,ږ��l��U�
-��CGĩ�����r��D�)���
�~X��(\-��8m�,��0��ܟ�@�}t��v/\��y\�:�
�?3�;Q±S}���J:96��7�Ŋ����[��;���Ξ�
#�
��Ų2�؄S2���@rV�2>������᛬I<Z	
ǵ7Wfo`�M�P�Hu�
-�t${��+q!�Q�3L7{Y�dz�>��	?9���R�(<۝���\ZĈ%���qvW���`v���K
+��)�*4�>{��K��O��B
+m����8��Tsb��j�Ҹ���~���댙k}H�� �2?��H�]�Xq> Pa�w
N�Vv��T��X㥇���Bı���jz8��;�
+	�Kؗ��*o4ؿ�b�wNN�����p}֎@�",�b�\�3�EN̅�L�*j��O���b}�ӅM9��ěe H�˳�P

data/README.adoc

@@ -915,14 +915,19 @@ 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
 
@@ -956,8 +961,11 @@ configuration disabled.
 
 === 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,
@@ -967,13 +975,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:
@@ -1013,9 +1030,14 @@ In addition to the objectives above, the following guidelines are worth followin
     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 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.
+* 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 `master` upon approval.
 * Avoid reviewing your own code review before rebasing onto `master`. Have another pair of eyes
   review your code first.

data/lib/git/lint/identity.rb

@@ -6,7 +6,7 @@ module Git
     module Identity
       NAME = "git-lint"
       LABEL = "Git Lint"
-      VERSION = "1.3.0"
+      VERSION = "1.4.0"
       VERSION_LABEL = "#{LABEL} #{VERSION}"
     end
   end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: git-lint
 version: !ruby/object:Gem::Version
-  version: 1.3.0
+  version: 1.4.0
 platform: ruby
 authors:
 - Brooke Kuhlmann
@@ -28,7 +28,7 @@ cert_chain:
   2XV8FRa7/JimI07sPLC13eLY3xd/aYTi85Z782KIA4j0G8XEEWAX0ouBhlXPocZv
   QWc=
   -----END CERTIFICATE-----
-date: 2020-11-15 00:00:00.000000000 Z
+date: 2020-12-13 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: pastel
@@ -50,14 +50,14 @@ dependencies:
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: '7.14'
+        version: '7.16'
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: '7.14'
+        version: '7.16'
 - !ruby/object:Gem::Dependency
   name: runcom
   requirement: !ruby/object:Gem::Requirement
@@ -86,202 +86,6 @@ dependencies:
     - - "~>"
       - !ruby/object:Gem::Version
         version: '0.20'
-- !ruby/object:Gem::Dependency
-  name: bundler-audit
-  requirement: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '0.7'
-  type: :development
-  prerelease: false
-  version_requirements: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '0.7'
-- !ruby/object:Gem::Dependency
-  name: bundler-leak
-  requirement: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '0.2'
-  type: :development
-  prerelease: false
-  version_requirements: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '0.2'
-- !ruby/object:Gem::Dependency
-  name: gemsmith
-  requirement: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '14.8'
-  type: :development
-  prerelease: false
-  version_requirements: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '14.8'
-- !ruby/object:Gem::Dependency
-  name: guard-rspec
-  requirement: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '4.7'
-  type: :development
-  prerelease: false
-  version_requirements: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '4.7'
-- !ruby/object:Gem::Dependency
-  name: pry
-  requirement: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '0.13'
-  type: :development
-  prerelease: false
-  version_requirements: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '0.13'
-- !ruby/object:Gem::Dependency
-  name: pry-byebug
-  requirement: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '3.9'
-  type: :development
-  prerelease: false
-  version_requirements: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '3.9'
-- !ruby/object:Gem::Dependency
-  name: rake
-  requirement: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '13.0'
-  type: :development
-  prerelease: false
-  version_requirements: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '13.0'
-- !ruby/object:Gem::Dependency
-  name: reek
-  requirement: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '6.0'
-  type: :development
-  prerelease: false
-  version_requirements: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '6.0'
-- !ruby/object:Gem::Dependency
-  name: rspec
-  requirement: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '3.10'
-  type: :development
-  prerelease: false
-  version_requirements: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '3.10'
-- !ruby/object:Gem::Dependency
-  name: rubocop
-  requirement: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '1.3'
-  type: :development
-  prerelease: false
-  version_requirements: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '1.3'
-- !ruby/object:Gem::Dependency
-  name: rubocop-performance
-  requirement: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '1.8'
-  type: :development
-  prerelease: false
-  version_requirements: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '1.8'
-- !ruby/object:Gem::Dependency
-  name: rubocop-rake
-  requirement: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '0.5'
-  type: :development
-  prerelease: false
-  version_requirements: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '0.5'
-- !ruby/object:Gem::Dependency
-  name: rubocop-rspec
-  requirement: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '2.0'
-  type: :development
-  prerelease: false
-  version_requirements: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '2.0'
-- !ruby/object:Gem::Dependency
-  name: simplecov
-  requirement: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '0.19'
-  type: :development
-  prerelease: false
-  version_requirements: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '0.19'
 description:
 email:
 - brooke@alchemists.io
@@ -371,7 +175,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
     - !ruby/object:Gem::Version
       version: '0'
 requirements: []
-rubygems_version: 3.1.4
+rubygems_version: 3.2.0
 signing_key:
 specification_version: 4
 summary: A command line interface for linting Git commits.