Hi Adam M, I would like to chime in on the items you mentioned, since I am currently working on the FINERACT-2462 implementation, and also had some ideas.
1. I agree that the squashing for multiple contributors per PR can get complicated, especially if changes are pulled between personal commits. I did a bit of research and found something that might be helpful. If we use “git commit --fixup=amend:<hash>”, along with “git rebase --autosquash”, we can target an old commit of ours by its hash and combine the local changes with the old changes for a single commit. The only downside is that the new changes made will be dated back at the first commit’s point in time. This also allows us to change the commit message to properly credit new contributors, testers, PMs, etc as they come in (for number 3). It’s still another step, but might be easier than a full interactive rebase. 2. The multiple contributors does complicate the FINERACT-2462 implementation. To update everyone, the complication is that multiple users per PR depends on contributors having their Git emails configured to one of their Github emails. This allows Github to properly show Github IDs for contributor differentiation. So we will have to enforce this email check to get the feature working. However, this check is not so difficult to add, as long as we all agree to this standard. 3. I was wondering if recording all contributors is something we can implement automatically. I was thinking maybe we can add a bot comment with Github Actions that properly credits PMs, designers, testers, and reviewers according to fields you set in your commit message and Github PR data. I think overall both solutions are fine with me as well. Just offering some thoughts. On Mon, Feb 2, 2026 at 1:53 PM Adam Monsen <[email protected]> wrote: > Yes, and someone else might also add some documentation. > > Thanks Ádám. I guess I'm finding I don't have a super strong preference > here so I'm happy to follow your lead. > > I'll augment and summarize my thoughts on multiple commits per PR. It: > > 1. complicates squashing for contributors -- they'll have to correctly > group theirs and others' commits (not in itself that complicated, but I'm > wary of adding more steps to the PR checklist) > 2. complicates the FINERACT-2462 implementation > 3. still leaves out other contributors (as I mentioned before) > > (Side note and FWIW, I'm not much a fan of squashing and rebasing just to > maintain one (or two) commits per PR... I prefer preserving as many commits > per bug/feature branch as necessary to document meaningful, understandable > steps in development and using traditional git merge commits. This > preserves fine-grained credit as well as the branch point, progress over > time, and merge point, and git has power tools for filtering history down > to what's useful in a given context, e.g. git log --simplify-by-decoration > .) > > On Mon, Feb 2, 2026 at 10:43 AM Ádám Sághy <[email protected]> wrote: > >> Hi Adam, >> >> In my opinion, the rule of one commit per PR was introduced to enhance >> the visibility of changes. However, in certain scenarios, it’s possible for >> a single developer and a test engineer to collaborate and submit their >> changes under a single PR. In such cases, I believe we should relax this >> rule and ensure that both parties receive the appropriate visibility and >> acknowledgment. >> >> I’d love to hear the community thoughts on this. >> >> Regards, >> Adam >> >> On Feb 2, 2026, at 7:36 PM, Adam Monsen <[email protected]> wrote: >> >> I'm confused by https://issues.apache.org/jira/browse/FINERACT-2462 . I >> thought we generally aim for *one commit per PR* in the apache/fineract >> repo, not one commit per person per PR. My suggestion is we stick with one >> commit per PR, and I wanted to open this up for discussion here in case I'm >> missing some change in convention or if there's something else I might >> learn. >> >> If you have thoughts on FINERACT-2462, please share. >> >> Wherever we end up, let's documented it somewhere useful, e.g.: >> >> - >> >> https://cwiki.apache.org/confluence/display/FINERACT/Submitting+a+Pull+Request >> - >> >> https://github.com/apache/fineract/blob/develop/.github/pull_request_template.md >> - >> >> https://github.com/apache/fineract/blob/develop/CONTRIBUTING.md#merge-strategy >> >> -- >> >> If the hope of preserving one commit per person per PR is to preserve >> credit, I think that's not a valid justification. I do think it's a great >> idea to credit more people other than the author and committer. In fact, >> many people (and bots) often work on a single PR, e.g.: a committer, >> authors, project managers, bots, designers, testers, and reviewers. I think >> a great place to add credit is the commit log message. I would like to see >> more detailed commit log messages anyway. We might add any number of >> trailers such as "Reviewed by:", "AI Assisted by:", "Designed by:", >> "Scheduled by:", and "Tested by:" per intended git commit trailer use >> <https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---trailertokenvalue> >> . >> >> >> -- Edward E. Kang [email protected] 972-768-6940
