More scalable approach to merging changes into Vim

[chrisbra]

Steps to reproduce

I have mentioned it in the past already, the current approach to merge C code changes into Vim is not scalable, because each change needs to get the patch number incremented. This probably comes from old times, when Vim was developed using CVS.

This means most of the changes are merged by me, but we have other maintainers here (and perhaps at one day I might get missing or on vacation) that should be allowed to merge changes into the Vim code.

So I am looking for ways how to automate incrementing the patch number. Personally I got used to the patch number, because it is immediately obvious when comparing two patches which one is newer (and when I am saying, that bug was fixed in version v9.1.X one easily knows later by looking at the current version, if that fix is included or not).

More importantly, I don't want to become a second BDFL. I am just a regular contributor, I don't feel like being the one single person having all the saying here and I'd like to listen to the community.

So I am open to discussions, what would be good approaches that are scalable and allow us to improve the current non-optimal way of merging changes into Vim.

All opinions welcome.

Thanks!

Expected behaviour

Version of Vim

9.1.0

Environment

Logs and stack traces

-

[zeertzjq]

This may be done by a CI job that check PRs for merging conditions, and then creates a commit that includes the PR plus an increment to the version number and closes the PR in the commit message, like how it's currently done. It'll need to take the remaining part of the commit message from somewhere, which can be a comment in the PR.

[koron]

We can hook events of PR merged by GitHub Actions.

https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#running-your-pull_request-workflow-when-a-pull-request-merges

[Shane-XB-Qian]

So I am looking for ways how to automate incrementing the patch number.

maybe just change to another kind of number, since we do need 'patch number' e.g for has('patch-xxx') check.
// it sounds like the problem what was done in p4 in the past? if i recalled correctly, or some others one, sounds similar.

[zzzyxwvut]

We all appreciate your hard work, Christian.

What if there were another permanent Git branch beside
master? And with it, some reviewing and merging effort be
delegated to another volunteering, seasoned member(s).

The runtime commits are not tagged: colors, documentation,
filetype, indent, keymap, syntax, translation. And there
should be very little merge conflicts with this hypothetical
branch(es) and C-tagged commits of master. Then, whoever
is at the helm of master can take in (fast-forward?) already
vetted and approved runtime commits.

[dundargoc]

git describe is usually the go-to method for projects to give a ref a human readable name. It can be adjusted to only give the number of commits since last tagged commit, which can be used to construct an equivalent patch number similar to the one currently used.

Using this method would allow merging pull requests normally without manual fiddling and also avoid introducing additional maintenance overhead or complicated CI automation.

A slight drawback of this is that tarball releases won't be able to calculate the patch number as the git history isn't there. This is in my opinion a small problem, but mentioning it for completeness sake.

[benknoble]

Now that runtime commits also come with patch number bumps, I suggest a workflow like the following:

• Provide a script in the source that automatically increments the patch number (my attempt later). This makes it easy for any maintainer to increment the patch number.
• Put this script in hooks/pre-commit and instruct maintainers to git config core.hooksPath hooks. This makes it so maintainer commits automatically include the patch bump. (In theory contributed patches could use this, too, but they probably should not, since that may induce more hassle for multiple maintainers pushing.) Note that using commit --no-verify will skip the pre-commit hook, in which case the script may need to be executed manually (but if you've already bumped the version, this is how you would skip bumping it again).
• Maintainers that plan to push patches should coordinate "stewardship" of PRs and patches on the mailing list, so that ultimately a single maintainer pushes the corresponding patch (if the push is rejected, git pull --rebase and, for conflicts with the patch, something like git checkout --ours src/version.c && hooks/pre-commit && git rebase --continue will work as long as the conflict is only the patch number). For PRs, I suggest "assigning" the PR in GitHub.
• All this should be documented somewhere.

---

Alternatively, a "seen" branch that maintainers could push patches without patch numbers to mark them as ready would be good; then a script to cherry-pick those commits with appropriate new patch numbers and any commit message tweaks could be used to migrate such patches to the master branch.

---

Here's my attempt to bump patch numbers; the only reliance on bash is for process substitution and heredocs. The vim commands could be put in a file and the script changed to be POSIX sh compatible. If there any problems, the script exits with an error (stopping the commit in the case of a pre-commit hook).

#! /bin/bash

cd "$(git rev-parse --show-toplevel)" || exit 1

vim -Nu NONE -S <(cat <<'EOF'
try
  autocmd SwapExists * let v:swapchoice = 'q'
  edit src/version.c
  /included_patches/,/\d\+,/
  let patch = getline('.')->matchstr('\d\+')->str2nr()
  let leading = getline('.')->matchstr('^\s*')
  -2put =['/**/', $'{leading}{patch+1},']
  wq
catch
  cquit
endtry
EOF
)

git add src/version.c