Summary
When a commit is marked as work in progress, the WIP: prefix adds five characters to
the header — W, I, P, : and the space. The 72-character header limit does not account
for them, so a header that is valid as a final commit can be invalid as a WIP commit.
Example
feat(grid-exporter): add support for exporting concatenated columns → 67 characters, valid
WIP: feat(grid-exporter): add support for exporting concatenated columns → 72 characters, rejected
A header five characters below the limit cannot be marked as work in progress. §3 states the
limit for the header line as a whole, and the only exception the document grants is the one
for revert:, so on a plain reading the prefix counts against the budget.
The developer then has to shorten the subject while the work is in progress and lengthen it
again when squashing — which defeats the purpose of writing the final message up front, and
is exactly what the WIP: type: subject form is meant to avoid (see #72).
This is the same contradiction that #61 resolved for reverts
#61 described it as a logical contradiction between two rules, and it applies verbatim here
with WIP: in place of revert::
- the header line must be less than 72 characters;
- a WIP commit must use the prefix
WIP:, followed by the full header of the in-progress
commit.
That issue was resolved by granting the prefix its own allowance, and the convention now
reads:
the length of the header line (including type and scope) must be less than 72 characters.
For revert: commits, the header line may be up to 80 characters, to allow room for the
full original header to be included without truncation.
Note the arithmetic chosen there: 72 + 8, where 8 is the length of revert: . Applying the
same formula to WIP: gives 77.
Proposal
Following #61 exactly, with 77 in place of 80:
Commits using the WIP: type are permitted to exceed the 72-character limit, up to a
maximum of 77 characters. This allows for the inclusion of the full header of the
in-progress commit without truncation.
Summary
When a commit is marked as work in progress, the
WIP:prefix adds five characters tothe header —
W,I,P,:and the space. The 72-character header limit does not accountfor them, so a header that is valid as a final commit can be invalid as a WIP commit.
Example
A header five characters below the limit cannot be marked as work in progress. §3 states the
limit for the header line as a whole, and the only exception the document grants is the one
for
revert:, so on a plain reading the prefix counts against the budget.The developer then has to shorten the subject while the work is in progress and lengthen it
again when squashing — which defeats the purpose of writing the final message up front, and
is exactly what the
WIP: type: subjectform is meant to avoid (see #72).This is the same contradiction that #61 resolved for reverts
#61 described it as a logical contradiction between two rules, and it applies verbatim here
with
WIP:in place ofrevert::WIP:, followed by the full header of the in-progresscommit.
That issue was resolved by granting the prefix its own allowance, and the convention now
reads:
Note the arithmetic chosen there: 72 + 8, where 8 is the length of
revert:. Applying thesame formula to
WIP:gives 77.Proposal
Following #61 exactly, with 77 in place of 80: