Releases: commonquail/commitmsgfmt
v1.6.0
This release introduces three new constructs:
- A block quote is any sequence of lines which begin with a greater-than sign (
>
). - A fenced code block is any sequence of lines framed by an opening and a closing code fence.
- A code fence is a sequence of at least three consecutive backticks (
`
), indented between 0 and 3 spaces and optionally followed by an infostring.- Outside of a fenced code block, any code fence is an opening code fence.
- Inside of a fenced code block, the earliest encountered code fence of which the opening code fence is a prefix is the closing code fence; indentation and infostring are disregarded.
All of these are printed verbatim and complement the original literal indented code block as more flexible, specialized variations of it.
Additionally, commitmsgfmt
has shed a substantial number of third-party dependencies, greatly reduced its memory consumption, and measurably reduced its execution time.
Full Changelog: v1.5.0...v1.6.0
v1.5.0
This release enhances the support for implicit non-breaking spaces introduced in v1.4.0:
- In addition to the original rules,
commitmsgfmt
now never breaks lines before words comprised entirely of sequences of punctuation; this generalizes the old rule for en-dashes to all other punctuation. - When a footnote reference is followed immediately by punctuation
commitmsgfmt
no longer fails to apply the non-breaking space rule.
Besides the above direct improvements, as an indirect improvement commitmsgfmt
now requires that blocks of footnotes be preceded by an empty line. This eliminates an edge case where a footnote reference would end up at the start of a new line, then immediately degrade into a footnote. The improvements mentioned above make this edge case much less likely to occur because of commitmsgfmt
but it can still occur for other reasons.
Full Changelog: v1.4.1...v1.5.0
v1.4.1
v1.4.0
This release adds support for implicit non-breaking spaces, which are normal ASCII spaces prohibited from turning into line breaks due to text analysis heuristics. This makes commitmsgfmt
wrap lines more safely and sensibly. The rules right now are:
- Never break immediately before a commit message comment character, which would cause the new line to degenerate into a comment.
- Never break immediately before an en-dash, which reads awkwardly.
- Never break immediately before footnote references, which reads awkwardly and would case the new line to degenerate into a list item.
The release also fixes an overflow problem that nobody would likely encounter.
The release bumps the Rust version to 1.41.1, available in openSUSE Leap 15.2, Debian "buster", and Ubuntu 16.04.
The Travis CI and AppVeyor deploy integrations have been replaced with a single GitHub Actions integration. This release publishes pre-compiled binaries for Linux, macOS, and Windows. Note that only the MSVC Windows version, which requires a separate runtime per the installation instructions, is provided. BSD support has been retired due to the many past build issues on Travis CI and, well, that nobody uses them.
Most of the individual changes in this release relate either to the new deploy integration, dependency upgrades, or adopting the Rust 2018 edition. Their only effect on the output is a negligible speed improvement from dependencies.
v1.3.0
This release makes commitmsgfmt
preserve subject lines that match the patterns supported by git rebase --autosquash
, to wit: fixup!
and squash!
. In most cases this change will likely be a no-op, but in the edge-case where, for instance, a user wishes to annotate such a "fixup" commit with details about what makes it worthwhile for a reviewer's benefit, commitmstfmt
would compromise any subject line above the length limit.
The release also bumps the Rust version to 1.34.2, the version shipped in Debian "buster".
Sadly both the Travis CI and AppVeyor deploy integrations have ossified since release v1.2.0 so this release only publishes pre-compiled binaries for Linux.
v1.2.0
This release changes line-breaking rules to yield a big speed-up and enable multi-line footnotes:
-
When wrapping a line, only do so at the last space before the line length limit; do not break any words to remain within the limit. "Words" that extend beyond the limit are not likely to be meaningfully breakable in the first place, and breaking is actively detrimental to URLs. This change alone yields a 6-8 times speed-up as reported by
time(1)
. -
References may span multiple lines, subsequent lines following the same indentation rules as list items. The syntactical unit has been renamed to footnote to better capture the new functionality.
v1.1.0
Changes in this release:
-
#3: Partial support for Git's
core.commentChar
setting. If it is set to an explicit comment character,commitmsgfmt
will use that character. If it is unset,commitmsgfmt
will use#
per Git's default. If it is set to the specialauto
value,commitmsgfmt
will ignore the setting and use#
. -
Vim integration: advise disabling
'textwidth'
in favour of'wrap'
.
v1.0.2
This is a minor release with the following fixes:
-
#4: AppVeyor builds work again and this release is available for Windows. v1.0.1 will remain unavailable.
-
#2:
commitmsgfmt
learned to recognize scissors and stop formatting lines from the first encountered scissor. This preserves the patch included bygit commit --verbose
. -
Some aesthetic version information was incorrect in v1.0.1. It is correct for v1.0.2 and should remain correct.
v1.0.1
This release fixes a minor error discovered while analysing commitmsgfmt
's performance where tab-indented list items with multiple lines would be rewritten to use spaces for continuation lines.
Unfortunately it is not possible to provide Windows binaries for this release because AppVeyor's default Ruby version only supports retired TLS versions and the build script does not account for that.
v1.0.0
First public release of commitmsgfmt
, a filter for formatting commit messages a little better than fmt(1)
and Vim.
This is the "make it work" version, and indeed, commitmsgfmt
is dog slow because of glaring big-O inefficiencies. Although embarrassing, this won't matter in the typical case; commitmsgfmt
can format its own history up until v1.0.0 in 20 milliseconds, and upwards of 90,000 words per second:
~/src/commitmsgfmt (master) $ git log --format=%B | wc
144 753 5401
~/src/commitmsgfmt (master) $ time commitmsgfmt < <(git log --format=%B) >/dev/null
real 0m0,017s
user 0m0,019s
sys 0m0,000s
~/src/commitmsgfmt (master) $ cd ../git/Documentation
~/src/git/Documentation ((v2.16.2)) $ wc gitcore-tutorial.txt
1661 9898 62275 gitcore-tutorial.txt
~/src/git/Documentation ((v2.16.2)) $ time commitmsgfmt < gitcore-tutorial.txt >/dev/null
real 0m0,101s
user 0m0,101s
sys 0m0,000s