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> > . > > >
