fix: wip
fix: wip

Check point

Commit source:
message
Effected files:
src/dotfiles/i3/base-config

ref-branch: master

# README below for info about the commit format
# <type>[optional scope]: <description>
#
# [optional body]
#
# [optional footer(s)]
#
# Example for WIP:
#
#   fix: wip
#
#   Safety check in
#
#   wip: Work in progress
#   ref: #DEF-<issue-number> or <branch-name>
#
#
# SEE: https://www.conventionalcommits.org/en/v1.0.0/#summary
#   AND https://git-scm.com/docs/git-interpret-trailers
#   AND https://gist.github.com/lisawolderiksen/a7b99d94c92c6671181611be1641c733
#
# The commit contains the following structural elements, to communicate intent to the consumers of your library:
#
# fix: a commit of the type fix patches a bug in your codebase (this correlates with PATCH in Semantic Versioning).
# feat: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in Semantic Versioning).
# BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope,
# introduces a breaking API change (correlating with MAJOR in Semantic Versioning).
# A BREAKING CHANGE can be part of commits of any type.
# types other than fix: and feat: are allowed, for example @commitlint/config-conventional (based on the the Angular convention) recommends
#   build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others.
# footers other than BREAKING CHANGE: <description> may be provided and follow a convention similar to git trailer format.
# Additional types are not mandated by the Conventional Commits specification,
# and have no implicit effect in Semantic Versioning (unless they include a BREAKING CHANGE).
# A scope may be provided to a commit’s type,
# to provide additional contextual information and is contained within parenthesis,
# e.g., 'feat(parser): add ability to parse arrays.'

jeffbuttars/env,jeffbuttars/env,jeffbuttars/env