-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
build(vim-patch.sh): include commit subject #28767
Conversation
We could possibly consider the 'new' commit message style starting from 11.0-dev cycle, if I may propose this. Though we might discuss first to have a consensus on which format would be the best for devs. Since the prefix might be a bit too lengthy, we could also consider some other alternatives like:
|
Actually the token only needs to have 7 hex digits: # Use sed…{7,7} to normalize (internal) Git hashes (for tokens caches).
git -C "${NVIM_SOURCE_DIR}" log -E --grep='vim-patch:[^ ,{]{7,}' \
| grep -oE 'vim-patch:[^ ,{:]{7,}' \
| sort \
| uniq \
| sed -nEe 's/^(vim-patch:([0-9]+\.[^ ]+|[0-9a-z]{7,7})).*/\1/p' # Check for vim-patch:<commit_hash> (usually runtime updates).
token="vim-patch:${line:0:7}"
if [[ "${tokens[$token]-}" ]]; then
continue
fi |
Problem: vim-patch commits lack an informative title and summary in the very first line of the commit message when the vim-revision is a Git SHA hash, unlike when is a Vim version. This makes it difficult to discern at a glance what changes are introduced by such vim-patch commits (in git log, PR title, changelog generated by git-cliff, etc.). e.g. Before: vim-patch:abcdef123456 runtime(vim): improve performance <some details> ... Solution: Repeat the title of the upstream commit message, to improve the clarity and visibility of the commit message. e.g. After: vim-patch:abcdef123456: runtime(vim): improve performance <some details> ... Note: the `vim-patch:<hash>` token is still needed by `vim-patch.sh` (but not necessarily in the very first line of the commit message) to determine which vim patches have been applied. `<hash>` is internally normalized to 7 hex digits.
a4641ac
to
2715513
Compare
For this PR I've drafted with not changing the number of hex digits, but I will leave to other core dev's decision whether to use 12 hex digits (current, since 03a0417), 7 digits, or other number of digits (say 8) --- if we think the title can be too length. I personally think being a bit lengthy for vim-patches is fine. |
I generally recommend 12 digits, but for vim-patch it's low risk. |
Problem: vim-patch commits lack an informative title and summary in the very first line of the commit message when the vim-revision is a Git SHA hash, unlike when is a Vim version. This makes it difficult to discern at a glance what changes are introduced by such vim-patch commits (in git log, PR title, changelog generated by git-cliff, etc.). BEFORE: vim-patch:abcdef123456 runtime(vim): improve performance <some details> ... Solution: Repeat the title of the upstream commit message, to improve the clarity and visibility of the commit message. AFTER: vim-patch:abcdef123456: runtime(vim): improve performance <some details> ... Note: the `vim-patch:<hash>` token is still needed by `vim-patch.sh` (but not necessarily in the very first line of the commit message) to determine which vim patches have been applied. `<hash>` is internally normalized to 7 hex digits.
Problem: vim-patch commits lack an informative title and summary in the
very first line of the commit message when the vim-revision is a Git SHA
hash, unlike when is a Vim version. This makes it difficult to discern
at a glance what changes are introduced by such vim-patch commits (in
git log, PR title, changelog generated by git-cliff, etc.).
e.g. Before:
Solution: Repeat the title of the upstream commit message, to improve
the clarity and visibility of the commit message.
e.g. After:
Note: the
vim-patch:<hash>
token is still needed byvim-patch.sh
(but not necessarily in the very first line of the commit message) to
determine which vim patches have been applied.