-
-
Notifications
You must be signed in to change notification settings - Fork 5.3k
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
More scalable approach to merging changes into Vim #14518
Comments
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. |
We can hook events of PR merged by GitHub Actions. |
maybe just change to another kind of number, since we do need 'patch number' e.g for |
We all appreciate your hard work, Christian. What if there were another permanent Git branch beside The |
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. |
Now that
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).
|
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
The text was updated successfully, but these errors were encountered: