Hi Adam M. Thanks for opening discussion on dev list, Let me clarify my intention for creating this ticket.
I noticed that maintainers have to notify new contributors everytime to squash their commits in PR. I think that. This can be automated. I have thought 2 different implementation based on this. 1. General GA check in PR open. This will notify the user to squash commits meanwhile I also noticed 2 commits merged in some PRs (so changed it into per person commit) 2. Another way this can be implemented via stale bot like check. Which automatically comments on every PR that not following convention. And based on what discussed here feel free to change the ticket requirement after conclusion. Regards, Aman Mittal On Tue, 3 Feb, 2026, 7:17 am Adam Monsen, <[email protected]> wrote: > Hi Edward! Thanks for your comments. Replies inline, below. > > I did a bit of research... > > > Fascinating. I've never used autosquash and I don't understand that > example. Based on the git-rebase(1) manpage it seems to be a way to avoid > an interactive rebase with carefully worded commit messages. Personally I'm > a big fan of interactive rebase so I probably wouldn't use it. I guess > folks can squash however they want. > > The multiple contributors does complicate the FINERACT-2462 >> implementation... > > > Thanks for this. I'm wary of adding more dependencies on github. I've seen > this codebase migrate between version control systems (from subversion to > git) and between code collaboration platforms (sourceforge to github), and > I imagine it'll happen again someday. Vendor lock-in complicates > migrations. I'm also wary of adding any friction to contributors trying to > submit patches (e.g. confirming correct email is being used). > > I was wondering if recording all contributors is something we can >> implement automatically... > > > I like this idea. Maybe it would work with the "trailers" idea? I think, > before we automate, the important first step here is reviewing what data we > currently have and gathering the new data we want while adding as little > friction as possible, and with just enough structure that we can pull out > something useful later. > > We have standard committer and author fields for commits, and extra data > captured by github during the PR process that is collated into all the > contributors when release notes are generated. If we can think of ways to > leverage that and write *less* or *no* code, that's even better. Could > you come up with conventions for our commit log messages, including > trailers? The commit could be force-pushed anytime before the PR is merged. >
