You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by Adam Monsen <am...@mifos.org> on 2026/02/02 18:36:36 UTC
one commit per PR
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>
.
Re: [one commit per PR] Solving for both clean history and contributor attribution
Posted by AYUSH SINGH <ay...@gmail.com>.
Hi everyone,
I’ve been catching up on the points raised by Adam, Nidhi, and Eduard. It
seems we’re caught between the desire for a clean Git history and the need
for fair contributor attribution.
To bridge this gap, I suggest we formalize the use of Git Trailers (e.g.,
Co-authored-by:) within our squash-merge workflow. This gives us the "one
commit" result while ensuring every contributor’s metadata is baked into
the permanent record and recognized by GitHub’s UI.
Question for the group: If I were to draft a brief standard for our
CONTRIBUTING.md on how to format these commit messages—or even look into a
GitHub Action to help automate the linting of these trailers—would that
alleviate the concerns about moving to this model?
I'd love to help get this over the finish line so we can keep the repo tidy
without losing the "human" history of the work.
Best,
Ayush Singh
On Tue, Feb 3, 2026, 7:17 AM Adam Monsen <am...@mifos.org> 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.
>
Re: one commit per PR
Posted by Edward Kang <ed...@gmail.com>.
Thank you Adam for the post!
It makes a lot of sense. I realize now from your post and other items like
the recent signed commits PR as well as context from last week's call that
we are moving towards adding more security in various aspects of Fineract,
including commits. I agree that from that frame of reference, One Commit
Per User is much better. Considering visibility can be achieved in both
methods, it seems the real tradeoff then is security vs cleaner git
history. After reconsidering myself, I personally agree that security is
the more pressing concern, as commit history will be organized by ticket
anyways.
Best,
Edward
On Thu, Feb 19, 2026 at 2:48 AM Ádám Sághy <ad...@gmail.com> wrote:
> Hi there,
>
> I still prefer the `One Commit Per User` approach. While I understand that
> the `Co-Authored-By` field might acknowledge the contribution, amending
> each other’s commits makes it more challenging to collaborate effectively
> and increases the likelihood of unintentionally overriding changes.
>
> Another important aspect to consider is that when the other party makes an
> amendment to the commit, the signature of the “original author” is also
> overridden.
>
> If I let my imagination run wild, here are a potential vulnerability:
>
> Commit message trailers can be easily forged.
> - Anyone can add the `Co-authored-by` field with my email address and name
> without my private key
>
> Regards,
> Adam
>
>
> > On Feb 18, 2026, at 10:16 PM, Edward Kang <ed...@gmail.com>
> wrote:
> >
> > Hi all!
> >
> > I decided to summarize everything we talked about to make it easier to
> make a decision.
> >
> > One Commit Per User
> > • More visibility for specifically test engineers, designers, etc with
> automatic Co-Authorship recognition by Github, meaning it will show on
> their Github profiles.
> > • Ability for each contributor to digitally sign their work.
> >
> > One Commit per PR
> > • Cleaner Git History
> > • Still has visibility with trailers to credit “missing actors”
> >
> > In my previous comment, I mentioned that only Co-Authored-By gets
> tracked for github contribution activity and contribution graph data. More
> on this here:
> https://docs.github.com/en/account-and-profile/concepts/contributions-on-your-profile.
>
> >
> > Given these tradeoffs, and the way Github gives out recognition, I had
> an extra idea we could consider. We could use One Commit Per PR (with
> trailers), but also make sure to add others like test engineers, designers,
> etc. specifically to the Co-Authored-By trailer, so they get full
> contribution recorded on their Github profiles as well. I think this might
> give us the best of both worlds with fine-grained contribution as well as
> contribution showing up on everyone's individual commit histories.
> >
> > So for example, if we have a test engineer and a software engineer
> collaborate. If the software engineer submits the PR, they would write the
> test engineer’s name on the Co-Authored-By and the Tested-By trailers. In
> this way, both would get full credit.
> >
> > What does everyone think about this idea?
> >
> >
> > On Mon, Feb 9, 2026 at 4:59 PM Edward Kang <ed...@gmail.com>
> wrote:
> > Hi everyone!
> >
> > After reading Aman's post, I also just realized that contributions
> clearly shown in the git history are actually really valuable for people
> like me trying to gain experience at the start of their careers, since
> commit history is often used as a signal for contribution. Notably, I found
> after a little reading that Co-Authored-By might get tracked, but other
> items like Tested-By and Designed-By would get passed over by Github. This
> means that if another contributor, let's say a test engineer, primarily
> does testing work on various PRs, others wouldn't be able to see that very
> easily on their Github profile.
> >
> > I do think that the trailers idea is great, because it lets us credit
> the missing actors (ie. designers, etc.). But given the above, maybe a mix
> of the two solutions would be a good idea?
> >
> > Best,
> > Ed
> >
> > On Mon, Feb 9, 2026 at 9:39 AM Aman Mittal <am...@gmail.com>
> wrote:
> > Hi all,
> > I wanted to raise one specific drawback to the “one PR → one commit”
> convention that doesn’t seem to have been highlighted yet, but often shows
> up in practice.
> > A single Git commit can only have one cryptographic signature and one
> author identity at the object level. In collaborative PRs where multiple
> people contribute, this means:
> > • only one person can be recorded as the commit author in the Git object,
> > • only one person can sign the commit (GPG/SSH),
> > • and additional contributors must be credited solely via commit-message
> trailers (e.g., Co-authored-by:).
> > Those trailers are widely recognized (GitHub, GitLab, etc.), but they
> are not part of the commit object’s authenticated metadata and aren’t
> enforced or interpreted by Git itself. In other words, the only thing that
> can be cryptographically attested is the signer’s identity, not that of
> other contributors to the change.
> > Practically this leads to:
> > • less accurate historical attribution in the authenticated Git history,
> > • a single signer implicitly asserting the entire change even when much
> of the work was done by others,
> > • and reliance on conventions that are easy to omit during squash merges.
> > This isn’t necessarily wrong, but it’s a real trade-off: history
> readability vs. fidelity of collaborative attribution and trust.
> > One possible angle for discussion is whether the convention should
> explicitly acknowledge this trade-off and offer guidance (e.g., explicitly
> include all co-authors in squash commits, or allow retaining individual
> commits when attribution matters for DCO/signing purposes).
> > Just my two cents — happy to expand if useful.
> > Regards,
> > Aman Mittal
> >
> > On Tue, Feb 3, 2026 at 2:57 PM Edward Kang <ed...@gmail.com>
> wrote:
> > Hi again Adam!
> >
> > First of all, thanks for all the wisdom here. I learned a lot from what
> you said, especially about vendor lock-in. I understand now that we want to
> keep the project flexible for future-proofing reasons.
> >
> > I also agree with everyone that Commit Trailers sound like a great idea.
> CoauthoredBy, ReviewedBy, ReportedBy, and TestedBy are important for credit
> purposes. We could also use DesignedBy, as this is not really available on
> Github or JIRA. Having this information would definitely help in reducing
> our reliance on these APIs that could go down anytime. In terms of naming
> scheme, I believe Github API gives us the entire commit message, which
> means we can pick and choose any trailer names we would like. I think we
> can honestly just go with something simple here, as long as it's
> consistent.
> >
> > Finally, for template schemes, you definitely know better than I do
> here. To add my 2 cents though, I think having some structure like
> problem::: solution might help descriptions flow more naturally. Just an
> idea.
> >
> > Here's an example. Could you let me know what you think?
> >
> > Fineract-0000: <Brief Description>
> >
> > Problem::: Solution
> > Next Problem::: Next Solution
> > Next Problem::: Next Solution
> >
> > < Additional Metadata >
> > CoAuthoredBy: First Last
> > ReviewedBy: First Last
> > TestedBy: First Last
> > DesignedBy: First Last
> > ReportedBy: First Last
> >
> > On Mon, Feb 2, 2026 at 10:52 PM Mohammed Saifulhuq <
> mohammed.saifulhuq@gmail.com> wrote:
> > Re: one commit per PR
> >
> > Hi everyone,
> > Adding my thoughts as a recent contributor.
> > I strongly support the "One Commit per PR" convention. From a
> maintainability standpoint, having a linear, clean history makes git bisect
> and reverting bad commits significantly easier in the future.
> > Regarding crediting multiple contributors: I agree with Adam M and Arnav
> that Git Trailers are the standard solution here. Specifically, using the
> standard Co-authored-by: Name <email> trailer is natively supported by
> GitHub and automatically links the commit to that user's profile in the UI.
> This solves the credit issue without polluting the commit log with
> intermediate "fix" commits.
> > +1 for documenting this clearly in CONTRIBUTING.md with a template for
> the trailers.
> > Regards, Mohammed Saifulhuq
> >
> >
> > On Tue, Feb 3, 2026 at 9:12 AM Arnav Patil <ap...@gmail.com> wrote:
> > Hi everyone,
> > Thanks for the detailed discussion — this thread has been really
> helpful, especially for contributors who are still learning the Fineract
> workflow.
> > From a contributor’s perspective, keeping one commit per PR as the
> default feels like a good baseline: it keeps history readable and reduces
> back-and-forth during reviews. At the same time, I agree with the concern
> that credit shouldn’t be lost when more than one person meaningfully
> contributes.
> > Using commit message trailers (e.g. Coauthored-by:, Reviewedby:,
> Testedby:) seems like a practical middle ground:
> > • preserves a clean commit history,
> > • avoids extra GitHub-specific enforcement,
> > • and still allows proper acknowledgment of everyone involved.
> > I also strongly agree that whatever convention we settle on should be
> clearly documented (CONTRIBUTING.md / PR template), ideally with simple
> examples for newer contributors (e.g. when to squash, how to add trailers).
> >
> > On Tue, Feb 3, 2026 at 8:17 AM Aman Mittal <am...@gmail.com>
> wrote:
> > 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, <am...@mifos.org> 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.
> >
> >
> > --
> > Edward E. Kang
> > edward.kang12@gmail.com
> > 972-768-6940
> >
> >
> > --
> > Edward E. Kang
> > edward.kang12@gmail.com
> > 972-768-6940
> >
> >
> > --
> > Edward E. Kang
> > edward.kang12@gmail.com
> > 972-768-6940
>
>
--
Edward E. Kang
edward.kang12@gmail.com
972-768-6940
Re: one commit per PR
Posted by Ádám Sághy <ad...@gmail.com>.
Hi there,
I still prefer the `One Commit Per User` approach. While I understand that the `Co-Authored-By` field might acknowledge the contribution, amending each other’s commits makes it more challenging to collaborate effectively and increases the likelihood of unintentionally overriding changes.
Another important aspect to consider is that when the other party makes an amendment to the commit, the signature of the “original author” is also overridden.
If I let my imagination run wild, here are a potential vulnerability:
Commit message trailers can be easily forged.
- Anyone can add the `Co-authored-by` field with my email address and name without my private key
Regards,
Adam
> On Feb 18, 2026, at 10:16 PM, Edward Kang <ed...@gmail.com> wrote:
>
> Hi all!
>
> I decided to summarize everything we talked about to make it easier to make a decision.
>
> One Commit Per User
> • More visibility for specifically test engineers, designers, etc with automatic Co-Authorship recognition by Github, meaning it will show on their Github profiles.
> • Ability for each contributor to digitally sign their work.
>
> One Commit per PR
> • Cleaner Git History
> • Still has visibility with trailers to credit “missing actors”
>
> In my previous comment, I mentioned that only Co-Authored-By gets tracked for github contribution activity and contribution graph data. More on this here: https://docs.github.com/en/account-and-profile/concepts/contributions-on-your-profile.
>
> Given these tradeoffs, and the way Github gives out recognition, I had an extra idea we could consider. We could use One Commit Per PR (with trailers), but also make sure to add others like test engineers, designers, etc. specifically to the Co-Authored-By trailer, so they get full contribution recorded on their Github profiles as well. I think this might give us the best of both worlds with fine-grained contribution as well as contribution showing up on everyone's individual commit histories.
>
> So for example, if we have a test engineer and a software engineer collaborate. If the software engineer submits the PR, they would write the test engineer’s name on the Co-Authored-By and the Tested-By trailers. In this way, both would get full credit.
>
> What does everyone think about this idea?
>
>
> On Mon, Feb 9, 2026 at 4:59 PM Edward Kang <ed...@gmail.com> wrote:
> Hi everyone!
>
> After reading Aman's post, I also just realized that contributions clearly shown in the git history are actually really valuable for people like me trying to gain experience at the start of their careers, since commit history is often used as a signal for contribution. Notably, I found after a little reading that Co-Authored-By might get tracked, but other items like Tested-By and Designed-By would get passed over by Github. This means that if another contributor, let's say a test engineer, primarily does testing work on various PRs, others wouldn't be able to see that very easily on their Github profile.
>
> I do think that the trailers idea is great, because it lets us credit the missing actors (ie. designers, etc.). But given the above, maybe a mix of the two solutions would be a good idea?
>
> Best,
> Ed
>
> On Mon, Feb 9, 2026 at 9:39 AM Aman Mittal <am...@gmail.com> wrote:
> Hi all,
> I wanted to raise one specific drawback to the “one PR → one commit” convention that doesn’t seem to have been highlighted yet, but often shows up in practice.
> A single Git commit can only have one cryptographic signature and one author identity at the object level. In collaborative PRs where multiple people contribute, this means:
> • only one person can be recorded as the commit author in the Git object,
> • only one person can sign the commit (GPG/SSH),
> • and additional contributors must be credited solely via commit-message trailers (e.g., Co-authored-by:).
> Those trailers are widely recognized (GitHub, GitLab, etc.), but they are not part of the commit object’s authenticated metadata and aren’t enforced or interpreted by Git itself. In other words, the only thing that can be cryptographically attested is the signer’s identity, not that of other contributors to the change.
> Practically this leads to:
> • less accurate historical attribution in the authenticated Git history,
> • a single signer implicitly asserting the entire change even when much of the work was done by others,
> • and reliance on conventions that are easy to omit during squash merges.
> This isn’t necessarily wrong, but it’s a real trade-off: history readability vs. fidelity of collaborative attribution and trust.
> One possible angle for discussion is whether the convention should explicitly acknowledge this trade-off and offer guidance (e.g., explicitly include all co-authors in squash commits, or allow retaining individual commits when attribution matters for DCO/signing purposes).
> Just my two cents — happy to expand if useful.
> Regards,
> Aman Mittal
>
> On Tue, Feb 3, 2026 at 2:57 PM Edward Kang <ed...@gmail.com> wrote:
> Hi again Adam!
>
> First of all, thanks for all the wisdom here. I learned a lot from what you said, especially about vendor lock-in. I understand now that we want to keep the project flexible for future-proofing reasons.
>
> I also agree with everyone that Commit Trailers sound like a great idea. CoauthoredBy, ReviewedBy, ReportedBy, and TestedBy are important for credit purposes. We could also use DesignedBy, as this is not really available on Github or JIRA. Having this information would definitely help in reducing our reliance on these APIs that could go down anytime. In terms of naming scheme, I believe Github API gives us the entire commit message, which means we can pick and choose any trailer names we would like. I think we can honestly just go with something simple here, as long as it's consistent.
>
> Finally, for template schemes, you definitely know better than I do here. To add my 2 cents though, I think having some structure like problem::: solution might help descriptions flow more naturally. Just an idea.
>
> Here's an example. Could you let me know what you think?
>
> Fineract-0000: <Brief Description>
>
> Problem::: Solution
> Next Problem::: Next Solution
> Next Problem::: Next Solution
>
> < Additional Metadata >
> CoAuthoredBy: First Last
> ReviewedBy: First Last
> TestedBy: First Last
> DesignedBy: First Last
> ReportedBy: First Last
>
> On Mon, Feb 2, 2026 at 10:52 PM Mohammed Saifulhuq <mo...@gmail.com> wrote:
> Re: one commit per PR
>
> Hi everyone,
> Adding my thoughts as a recent contributor.
> I strongly support the "One Commit per PR" convention. From a maintainability standpoint, having a linear, clean history makes git bisect and reverting bad commits significantly easier in the future.
> Regarding crediting multiple contributors: I agree with Adam M and Arnav that Git Trailers are the standard solution here. Specifically, using the standard Co-authored-by: Name <email> trailer is natively supported by GitHub and automatically links the commit to that user's profile in the UI. This solves the credit issue without polluting the commit log with intermediate "fix" commits.
> +1 for documenting this clearly in CONTRIBUTING.md with a template for the trailers.
> Regards, Mohammed Saifulhuq
>
>
> On Tue, Feb 3, 2026 at 9:12 AM Arnav Patil <ap...@gmail.com> wrote:
> Hi everyone,
> Thanks for the detailed discussion — this thread has been really helpful, especially for contributors who are still learning the Fineract workflow.
> From a contributor’s perspective, keeping one commit per PR as the default feels like a good baseline: it keeps history readable and reduces back-and-forth during reviews. At the same time, I agree with the concern that credit shouldn’t be lost when more than one person meaningfully contributes.
> Using commit message trailers (e.g. Coauthored-by:, Reviewedby:, Testedby:) seems like a practical middle ground:
> • preserves a clean commit history,
> • avoids extra GitHub-specific enforcement,
> • and still allows proper acknowledgment of everyone involved.
> I also strongly agree that whatever convention we settle on should be clearly documented (CONTRIBUTING.md / PR template), ideally with simple examples for newer contributors (e.g. when to squash, how to add trailers).
>
> On Tue, Feb 3, 2026 at 8:17 AM Aman Mittal <am...@gmail.com> wrote:
> 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, <am...@mifos.org> 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.
>
>
> --
> Edward E. Kang
> edward.kang12@gmail.com
> 972-768-6940
>
>
> --
> Edward E. Kang
> edward.kang12@gmail.com
> 972-768-6940
>
>
> --
> Edward E. Kang
> edward.kang12@gmail.com
> 972-768-6940
Re: one commit per PR
Posted by Edward Kang <ed...@gmail.com>.
Hi all!
I decided to summarize everything we talked about to make it easier to make
a decision.
One Commit Per User
- More visibility for specifically test engineers, designers, etc with
automatic Co-Authorship recognition by Github, meaning it will show on
their Github profiles.
- Ability for each contributor to digitally sign their work.
One Commit per PR
- Cleaner Git History
- Still has visibility with trailers to credit “missing actors”
In my previous comment, I mentioned that only Co-Authored-By gets tracked
for github contribution activity and contribution graph data. More on this
here:
https://docs.github.com/en/account-and-profile/concepts/contributions-on-your-profile
.
Given these tradeoffs, and the way Github gives out recognition, I had an
extra idea we could consider. We could use One Commit Per PR (with
trailers), but also make sure to add others like test engineers, designers,
etc. specifically to the Co-Authored-By trailer, so they get full
contribution recorded on their Github profiles as well. I think this might
give us the best of both worlds with fine-grained contribution as well as
contribution showing up on everyone's individual commit histories.
So for example, if we have a test engineer and a software engineer
collaborate. If the software engineer submits the PR, they would write the
test engineer’s name on the Co-Authored-By and the Tested-By trailers. In
this way, both would get full credit.
What does everyone think about this idea?
On Mon, Feb 9, 2026 at 4:59 PM Edward Kang <ed...@gmail.com> wrote:
> Hi everyone!
>
> After reading Aman's post, I also just realized that contributions clearly
> shown in the git history are actually really valuable for people like me
> trying to gain experience at the start of their careers, since commit
> history is often used as a signal for contribution. Notably, I found after
> a little reading that Co-Authored-By might get tracked, but other items
> like Tested-By and Designed-By would get passed over by Github. This means
> that if another contributor, let's say a test engineer, primarily does
> testing work on various PRs, others wouldn't be able to see that very
> easily on their Github profile.
>
> I do think that the trailers idea is great, because it lets us credit the
> missing actors (ie. designers, etc.). But given the above, maybe a mix of
> the two solutions would be a good idea?
>
> Best,
>
> Ed
>
>
> On Mon, Feb 9, 2026 at 9:39 AM Aman Mittal <am...@gmail.com>
> wrote:
>
>> Hi all,
>>
>> I wanted to raise one specific drawback to the “one PR → one commit”
>> convention that doesn’t seem to have been highlighted yet, but often shows
>> up in practice.
>>
>> A single Git commit *can only have one cryptographic signature* and *one
>> author identity* at the object level. In collaborative PRs where
>> multiple people contribute, this means:
>>
>> -
>>
>> only one person can be recorded as the commit *author* in the Git
>> object,
>> -
>>
>> only one person can *sign* the commit (GPG/SSH),
>> -
>>
>> and additional contributors must be credited solely via
>> commit-message trailers (e.g., Co-authored-by:).
>>
>> Those trailers are widely recognized (GitHub, GitLab, etc.), but they are *not
>> part of the commit object’s authenticated metadata* and aren’t enforced
>> or interpreted by Git itself. In other words, the only thing that can be
>> cryptographically attested is the signer’s identity, not that of other
>> contributors to the change.
>>
>> Practically this leads to:
>>
>> -
>>
>> less accurate historical attribution in the authenticated Git history,
>> -
>>
>> a single signer implicitly asserting the entire change even when much
>> of the work was done by others,
>> -
>>
>> and reliance on conventions that are easy to omit during squash
>> merges.
>>
>> This isn’t necessarily *wrong*, but it’s a real trade-off: *history
>> readability vs. fidelity of collaborative attribution and trust*.
>>
>> One possible angle for discussion is whether the convention should
>> explicitly acknowledge this trade-off and offer guidance (e.g., explicitly
>> include all co-authors in squash commits, or allow retaining individual
>> commits when attribution matters for DCO/signing purposes).
>>
>> Just my two cents — happy to expand if useful.
>>
>> Regards,
>>
>> Aman Mittal
>>
>> On Tue, Feb 3, 2026 at 2:57 PM Edward Kang <ed...@gmail.com>
>> wrote:
>>
>>> Hi again Adam!
>>>
>>> First of all, thanks for all the wisdom here. I learned a lot from what
>>> you said, especially about vendor lock-in. I understand now that we want to
>>> keep the project flexible for future-proofing reasons.
>>>
>>> I also agree with everyone that Commit Trailers sound like a great idea.
>>> CoauthoredBy, ReviewedBy, ReportedBy, and TestedBy are important for credit
>>> purposes. We could also use DesignedBy, as this is not really available on
>>> Github or JIRA. Having this information would definitely help in reducing
>>> our reliance on these APIs that could go down anytime. In terms of naming
>>> scheme, I believe Github API gives us the entire commit message, which
>>> means we can pick and choose any trailer names we would like. I think we
>>> can honestly just go with something simple here, as long as it's
>>> consistent.
>>>
>>> Finally, for template schemes, you definitely know better than I do
>>> here. To add my 2 cents though, I think having some structure like
>>> problem::: solution might help descriptions flow more naturally. Just an
>>> idea.
>>>
>>> Here's an example. Could you let me know what you think?
>>>
>>> Fineract-0000: <Brief Description>
>>>
>>> Problem::: Solution
>>> Next Problem::: Next Solution
>>> Next Problem::: Next Solution
>>>
>>> < Additional Metadata >
>>> CoAuthoredBy: First Last
>>> ReviewedBy: First Last
>>> TestedBy: First Last
>>> DesignedBy: First Last
>>> ReportedBy: First Last
>>>
>>> On Mon, Feb 2, 2026 at 10:52 PM Mohammed Saifulhuq <
>>> mohammed.saifulhuq@gmail.com> wrote:
>>>
>>>> Re: one commit per PR
>>>>
>>>> Hi everyone,
>>>>
>>>> Adding my thoughts as a recent contributor.
>>>>
>>>> I strongly support the *"One Commit per PR"* convention. From a
>>>> maintainability standpoint, having a linear, clean history makes git
>>>> bisect and reverting bad commits significantly easier in the future.
>>>>
>>>> Regarding crediting multiple contributors: I agree with Adam M and
>>>> Arnav that *Git Trailers* are the standard solution here.
>>>> Specifically, using the standard Co-authored-by: Name <email> trailer
>>>> is natively supported by GitHub and automatically links the commit to that
>>>> user's profile in the UI. This solves the credit issue without polluting
>>>> the commit log with intermediate "fix" commits.
>>>>
>>>> +1 for documenting this clearly in CONTRIBUTING.md with a template for
>>>> the trailers.
>>>>
>>>> Regards, Mohammed Saifulhuq
>>>>
>>>>
>>>> On Tue, Feb 3, 2026 at 9:12 AM Arnav Patil <ap...@gmail.com> wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> Thanks for the detailed discussion — this thread has been really
>>>>> helpful, especially for contributors who are still learning the Fineract
>>>>> workflow.
>>>>>
>>>>> From a contributor’s perspective, keeping one commit per PR as the
>>>>> default feels like a good baseline: it keeps history readable and reduces
>>>>> back-and-forth during reviews. At the same time, I agree with the concern
>>>>> that credit shouldn’t be lost when more than one person meaningfully
>>>>> contributes.
>>>>>
>>>>> Using commit message trailers (e.g. Coauthored-by:, Reviewedby:,
>>>>> Testedby:) seems like a practical middle ground:
>>>>>
>>>>> -
>>>>>
>>>>> preserves a clean commit history,
>>>>> -
>>>>>
>>>>> avoids extra GitHub-specific enforcement,
>>>>> -
>>>>>
>>>>> and still allows proper acknowledgment of everyone involved.
>>>>>
>>>>> I also strongly agree that whatever convention we settle on should be
>>>>> clearly documented (CONTRIBUTING.md / PR template), ideally with simple
>>>>> examples for newer contributors (e.g. when to squash, how to add trailers).
>>>>>
>>>>> On Tue, Feb 3, 2026 at 8:17 AM Aman Mittal <
>>>>> aman.mittal3052000@gmail.com> wrote:
>>>>>
>>>>>> 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, <am...@mifos.org> 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.
>>>>>>>
>>>>>>
>>>
>>> --
>>> Edward E. Kang
>>> edward.kang12@gmail.com
>>> 972-768-6940
>>>
>>
>
> --
> Edward E. Kang
> edward.kang12@gmail.com
> 972-768-6940
>
--
Edward E. Kang
edward.kang12@gmail.com
972-768-6940
Re: one commit per PR
Posted by Edward Kang <ed...@gmail.com>.
Hi everyone!
After reading Aman's post, I also just realized that contributions clearly
shown in the git history are actually really valuable for people like me
trying to gain experience at the start of their careers, since commit
history is often used as a signal for contribution. Notably, I found after
a little reading that Co-Authored-By might get tracked, but other items
like Tested-By and Designed-By would get passed over by Github. This means
that if another contributor, let's say a test engineer, primarily does
testing work on various PRs, others wouldn't be able to see that very
easily on their Github profile.
I do think that the trailers idea is great, because it lets us credit the
missing actors (ie. designers, etc.). But given the above, maybe a mix of
the two solutions would be a good idea?
Best,
Ed
On Mon, Feb 9, 2026 at 9:39 AM Aman Mittal <am...@gmail.com>
wrote:
> Hi all,
>
> I wanted to raise one specific drawback to the “one PR → one commit”
> convention that doesn’t seem to have been highlighted yet, but often shows
> up in practice.
>
> A single Git commit *can only have one cryptographic signature* and *one
> author identity* at the object level. In collaborative PRs where multiple
> people contribute, this means:
>
> -
>
> only one person can be recorded as the commit *author* in the Git
> object,
> -
>
> only one person can *sign* the commit (GPG/SSH),
> -
>
> and additional contributors must be credited solely via commit-message
> trailers (e.g., Co-authored-by:).
>
> Those trailers are widely recognized (GitHub, GitLab, etc.), but they are *not
> part of the commit object’s authenticated metadata* and aren’t enforced
> or interpreted by Git itself. In other words, the only thing that can be
> cryptographically attested is the signer’s identity, not that of other
> contributors to the change.
>
> Practically this leads to:
>
> -
>
> less accurate historical attribution in the authenticated Git history,
> -
>
> a single signer implicitly asserting the entire change even when much
> of the work was done by others,
> -
>
> and reliance on conventions that are easy to omit during squash merges.
>
> This isn’t necessarily *wrong*, but it’s a real trade-off: *history
> readability vs. fidelity of collaborative attribution and trust*.
>
> One possible angle for discussion is whether the convention should
> explicitly acknowledge this trade-off and offer guidance (e.g., explicitly
> include all co-authors in squash commits, or allow retaining individual
> commits when attribution matters for DCO/signing purposes).
>
> Just my two cents — happy to expand if useful.
>
> Regards,
>
> Aman Mittal
>
> On Tue, Feb 3, 2026 at 2:57 PM Edward Kang <ed...@gmail.com>
> wrote:
>
>> Hi again Adam!
>>
>> First of all, thanks for all the wisdom here. I learned a lot from what
>> you said, especially about vendor lock-in. I understand now that we want to
>> keep the project flexible for future-proofing reasons.
>>
>> I also agree with everyone that Commit Trailers sound like a great idea.
>> CoauthoredBy, ReviewedBy, ReportedBy, and TestedBy are important for credit
>> purposes. We could also use DesignedBy, as this is not really available on
>> Github or JIRA. Having this information would definitely help in reducing
>> our reliance on these APIs that could go down anytime. In terms of naming
>> scheme, I believe Github API gives us the entire commit message, which
>> means we can pick and choose any trailer names we would like. I think we
>> can honestly just go with something simple here, as long as it's
>> consistent.
>>
>> Finally, for template schemes, you definitely know better than I do here.
>> To add my 2 cents though, I think having some structure like problem:::
>> solution might help descriptions flow more naturally. Just an idea.
>>
>> Here's an example. Could you let me know what you think?
>>
>> Fineract-0000: <Brief Description>
>>
>> Problem::: Solution
>> Next Problem::: Next Solution
>> Next Problem::: Next Solution
>>
>> < Additional Metadata >
>> CoAuthoredBy: First Last
>> ReviewedBy: First Last
>> TestedBy: First Last
>> DesignedBy: First Last
>> ReportedBy: First Last
>>
>> On Mon, Feb 2, 2026 at 10:52 PM Mohammed Saifulhuq <
>> mohammed.saifulhuq@gmail.com> wrote:
>>
>>> Re: one commit per PR
>>>
>>> Hi everyone,
>>>
>>> Adding my thoughts as a recent contributor.
>>>
>>> I strongly support the *"One Commit per PR"* convention. From a
>>> maintainability standpoint, having a linear, clean history makes git
>>> bisect and reverting bad commits significantly easier in the future.
>>>
>>> Regarding crediting multiple contributors: I agree with Adam M and Arnav
>>> that *Git Trailers* are the standard solution here. Specifically, using
>>> the standard Co-authored-by: Name <email> trailer is natively supported
>>> by GitHub and automatically links the commit to that user's profile in the
>>> UI. This solves the credit issue without polluting the commit log with
>>> intermediate "fix" commits.
>>>
>>> +1 for documenting this clearly in CONTRIBUTING.md with a template for
>>> the trailers.
>>>
>>> Regards, Mohammed Saifulhuq
>>>
>>>
>>> On Tue, Feb 3, 2026 at 9:12 AM Arnav Patil <ap...@gmail.com> wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> Thanks for the detailed discussion — this thread has been really
>>>> helpful, especially for contributors who are still learning the Fineract
>>>> workflow.
>>>>
>>>> From a contributor’s perspective, keeping one commit per PR as the
>>>> default feels like a good baseline: it keeps history readable and reduces
>>>> back-and-forth during reviews. At the same time, I agree with the concern
>>>> that credit shouldn’t be lost when more than one person meaningfully
>>>> contributes.
>>>>
>>>> Using commit message trailers (e.g. Coauthored-by:, Reviewedby:,
>>>> Testedby:) seems like a practical middle ground:
>>>>
>>>> -
>>>>
>>>> preserves a clean commit history,
>>>> -
>>>>
>>>> avoids extra GitHub-specific enforcement,
>>>> -
>>>>
>>>> and still allows proper acknowledgment of everyone involved.
>>>>
>>>> I also strongly agree that whatever convention we settle on should be
>>>> clearly documented (CONTRIBUTING.md / PR template), ideally with simple
>>>> examples for newer contributors (e.g. when to squash, how to add trailers).
>>>>
>>>> On Tue, Feb 3, 2026 at 8:17 AM Aman Mittal <
>>>> aman.mittal3052000@gmail.com> wrote:
>>>>
>>>>> 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, <am...@mifos.org> 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.
>>>>>>
>>>>>
>>
>> --
>> Edward E. Kang
>> edward.kang12@gmail.com
>> 972-768-6940
>>
>
--
Edward E. Kang
edward.kang12@gmail.com
972-768-6940
Re: one commit per PR
Posted by Aman Mittal <am...@gmail.com>.
Hi all,
I wanted to raise one specific drawback to the “one PR → one commit”
convention that doesn’t seem to have been highlighted yet, but often shows
up in practice.
A single Git commit *can only have one cryptographic signature* and *one
author identity* at the object level. In collaborative PRs where multiple
people contribute, this means:
-
only one person can be recorded as the commit *author* in the Git object,
-
only one person can *sign* the commit (GPG/SSH),
-
and additional contributors must be credited solely via commit-message
trailers (e.g., Co-authored-by:).
Those trailers are widely recognized (GitHub, GitLab, etc.), but they are *not
part of the commit object’s authenticated metadata* and aren’t enforced or
interpreted by Git itself. In other words, the only thing that can be
cryptographically attested is the signer’s identity, not that of other
contributors to the change.
Practically this leads to:
-
less accurate historical attribution in the authenticated Git history,
-
a single signer implicitly asserting the entire change even when much of
the work was done by others,
-
and reliance on conventions that are easy to omit during squash merges.
This isn’t necessarily *wrong*, but it’s a real trade-off: *history
readability vs. fidelity of collaborative attribution and trust*.
One possible angle for discussion is whether the convention should
explicitly acknowledge this trade-off and offer guidance (e.g., explicitly
include all co-authors in squash commits, or allow retaining individual
commits when attribution matters for DCO/signing purposes).
Just my two cents — happy to expand if useful.
Regards,
Aman Mittal
On Tue, Feb 3, 2026 at 2:57 PM Edward Kang <ed...@gmail.com> wrote:
> Hi again Adam!
>
> First of all, thanks for all the wisdom here. I learned a lot from what
> you said, especially about vendor lock-in. I understand now that we want to
> keep the project flexible for future-proofing reasons.
>
> I also agree with everyone that Commit Trailers sound like a great idea.
> CoauthoredBy, ReviewedBy, ReportedBy, and TestedBy are important for credit
> purposes. We could also use DesignedBy, as this is not really available on
> Github or JIRA. Having this information would definitely help in reducing
> our reliance on these APIs that could go down anytime. In terms of naming
> scheme, I believe Github API gives us the entire commit message, which
> means we can pick and choose any trailer names we would like. I think we
> can honestly just go with something simple here, as long as it's
> consistent.
>
> Finally, for template schemes, you definitely know better than I do here.
> To add my 2 cents though, I think having some structure like problem:::
> solution might help descriptions flow more naturally. Just an idea.
>
> Here's an example. Could you let me know what you think?
>
> Fineract-0000: <Brief Description>
>
> Problem::: Solution
> Next Problem::: Next Solution
> Next Problem::: Next Solution
>
> < Additional Metadata >
> CoAuthoredBy: First Last
> ReviewedBy: First Last
> TestedBy: First Last
> DesignedBy: First Last
> ReportedBy: First Last
>
> On Mon, Feb 2, 2026 at 10:52 PM Mohammed Saifulhuq <
> mohammed.saifulhuq@gmail.com> wrote:
>
>> Re: one commit per PR
>>
>> Hi everyone,
>>
>> Adding my thoughts as a recent contributor.
>>
>> I strongly support the *"One Commit per PR"* convention. From a
>> maintainability standpoint, having a linear, clean history makes git
>> bisect and reverting bad commits significantly easier in the future.
>>
>> Regarding crediting multiple contributors: I agree with Adam M and Arnav
>> that *Git Trailers* are the standard solution here. Specifically, using
>> the standard Co-authored-by: Name <email> trailer is natively supported
>> by GitHub and automatically links the commit to that user's profile in the
>> UI. This solves the credit issue without polluting the commit log with
>> intermediate "fix" commits.
>>
>> +1 for documenting this clearly in CONTRIBUTING.md with a template for
>> the trailers.
>>
>> Regards, Mohammed Saifulhuq
>>
>>
>> On Tue, Feb 3, 2026 at 9:12 AM Arnav Patil <ap...@gmail.com> wrote:
>>
>>> Hi everyone,
>>>
>>> Thanks for the detailed discussion — this thread has been really
>>> helpful, especially for contributors who are still learning the Fineract
>>> workflow.
>>>
>>> From a contributor’s perspective, keeping one commit per PR as the
>>> default feels like a good baseline: it keeps history readable and reduces
>>> back-and-forth during reviews. At the same time, I agree with the concern
>>> that credit shouldn’t be lost when more than one person meaningfully
>>> contributes.
>>>
>>> Using commit message trailers (e.g. Coauthored-by:, Reviewedby:,
>>> Testedby:) seems like a practical middle ground:
>>>
>>> -
>>>
>>> preserves a clean commit history,
>>> -
>>>
>>> avoids extra GitHub-specific enforcement,
>>> -
>>>
>>> and still allows proper acknowledgment of everyone involved.
>>>
>>> I also strongly agree that whatever convention we settle on should be
>>> clearly documented (CONTRIBUTING.md / PR template), ideally with simple
>>> examples for newer contributors (e.g. when to squash, how to add trailers).
>>>
>>> On Tue, Feb 3, 2026 at 8:17 AM Aman Mittal <am...@gmail.com>
>>> wrote:
>>>
>>>> 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, <am...@mifos.org> 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.
>>>>>
>>>>
>
> --
> Edward E. Kang
> edward.kang12@gmail.com
> 972-768-6940
>
Re: one commit per PR
Posted by Edward Kang <ed...@gmail.com>.
Hi again Adam!
First of all, thanks for all the wisdom here. I learned a lot from what you
said, especially about vendor lock-in. I understand now that we want to
keep the project flexible for future-proofing reasons.
I also agree with everyone that Commit Trailers sound like a great idea.
CoauthoredBy, ReviewedBy, ReportedBy, and TestedBy are important for credit
purposes. We could also use DesignedBy, as this is not really available on
Github or JIRA. Having this information would definitely help in reducing
our reliance on these APIs that could go down anytime. In terms of naming
scheme, I believe Github API gives us the entire commit message, which
means we can pick and choose any trailer names we would like. I think we
can honestly just go with something simple here, as long as it's
consistent.
Finally, for template schemes, you definitely know better than I do here.
To add my 2 cents though, I think having some structure like problem:::
solution might help descriptions flow more naturally. Just an idea.
Here's an example. Could you let me know what you think?
Fineract-0000: <Brief Description>
Problem::: Solution
Next Problem::: Next Solution
Next Problem::: Next Solution
< Additional Metadata >
CoAuthoredBy: First Last
ReviewedBy: First Last
TestedBy: First Last
DesignedBy: First Last
ReportedBy: First Last
On Mon, Feb 2, 2026 at 10:52 PM Mohammed Saifulhuq <
mohammed.saifulhuq@gmail.com> wrote:
> Re: one commit per PR
>
> Hi everyone,
>
> Adding my thoughts as a recent contributor.
>
> I strongly support the *"One Commit per PR"* convention. From a
> maintainability standpoint, having a linear, clean history makes git
> bisect and reverting bad commits significantly easier in the future.
>
> Regarding crediting multiple contributors: I agree with Adam M and Arnav
> that *Git Trailers* are the standard solution here. Specifically, using
> the standard Co-authored-by: Name <email> trailer is natively supported
> by GitHub and automatically links the commit to that user's profile in the
> UI. This solves the credit issue without polluting the commit log with
> intermediate "fix" commits.
>
> +1 for documenting this clearly in CONTRIBUTING.md with a template for
> the trailers.
>
> Regards, Mohammed Saifulhuq
>
>
> On Tue, Feb 3, 2026 at 9:12 AM Arnav Patil <ap...@gmail.com> wrote:
>
>> Hi everyone,
>>
>> Thanks for the detailed discussion — this thread has been really helpful,
>> especially for contributors who are still learning the Fineract workflow.
>>
>> From a contributor’s perspective, keeping one commit per PR as the
>> default feels like a good baseline: it keeps history readable and reduces
>> back-and-forth during reviews. At the same time, I agree with the concern
>> that credit shouldn’t be lost when more than one person meaningfully
>> contributes.
>>
>> Using commit message trailers (e.g. Coauthored-by:, Reviewedby:,
>> Testedby:) seems like a practical middle ground:
>>
>> -
>>
>> preserves a clean commit history,
>> -
>>
>> avoids extra GitHub-specific enforcement,
>> -
>>
>> and still allows proper acknowledgment of everyone involved.
>>
>> I also strongly agree that whatever convention we settle on should be
>> clearly documented (CONTRIBUTING.md / PR template), ideally with simple
>> examples for newer contributors (e.g. when to squash, how to add trailers).
>>
>> On Tue, Feb 3, 2026 at 8:17 AM Aman Mittal <am...@gmail.com>
>> wrote:
>>
>>> 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, <am...@mifos.org> 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.
>>>>
>>>
--
Edward E. Kang
edward.kang12@gmail.com
972-768-6940
Re: one commit per PR
Posted by Mohammed Saifulhuq <mo...@gmail.com>.
Re: one commit per PR
Hi everyone,
Adding my thoughts as a recent contributor.
I strongly support the *"One Commit per PR"* convention. From a
maintainability standpoint, having a linear, clean history makes git bisect
and reverting bad commits significantly easier in the future.
Regarding crediting multiple contributors: I agree with Adam M and Arnav
that *Git Trailers* are the standard solution here. Specifically, using the
standard Co-authored-by: Name <email> trailer is natively supported by
GitHub and automatically links the commit to that user's profile in the UI.
This solves the credit issue without polluting the commit log with
intermediate "fix" commits.
+1 for documenting this clearly in CONTRIBUTING.md with a template for the
trailers.
Regards, Mohammed Saifulhuq
On Tue, Feb 3, 2026 at 9:12 AM Arnav Patil <ap...@gmail.com> wrote:
> Hi everyone,
>
> Thanks for the detailed discussion — this thread has been really helpful,
> especially for contributors who are still learning the Fineract workflow.
>
> From a contributor’s perspective, keeping one commit per PR as the default
> feels like a good baseline: it keeps history readable and reduces
> back-and-forth during reviews. At the same time, I agree with the concern
> that credit shouldn’t be lost when more than one person meaningfully
> contributes.
>
> Using commit message trailers (e.g. Coauthored-by:, Reviewedby:, Testedby:)
> seems like a practical middle ground:
>
> -
>
> preserves a clean commit history,
> -
>
> avoids extra GitHub-specific enforcement,
> -
>
> and still allows proper acknowledgment of everyone involved.
>
> I also strongly agree that whatever convention we settle on should be
> clearly documented (CONTRIBUTING.md / PR template), ideally with simple
> examples for newer contributors (e.g. when to squash, how to add trailers).
>
> On Tue, Feb 3, 2026 at 8:17 AM Aman Mittal <am...@gmail.com>
> wrote:
>
>> 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, <am...@mifos.org> 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.
>>>
>>
Re: one commit per PR
Posted by Arnav Patil <ap...@gmail.com>.
Hi everyone,
Thanks for the detailed discussion — this thread has been really helpful,
especially for contributors who are still learning the Fineract workflow.
From a contributor’s perspective, keeping one commit per PR as the default
feels like a good baseline: it keeps history readable and reduces
back-and-forth during reviews. At the same time, I agree with the concern
that credit shouldn’t be lost when more than one person meaningfully
contributes.
Using commit message trailers (e.g. Coauthored-by:, Reviewedby:, Testedby:)
seems like a practical middle ground:
-
preserves a clean commit history,
-
avoids extra GitHub-specific enforcement,
-
and still allows proper acknowledgment of everyone involved.
I also strongly agree that whatever convention we settle on should be
clearly documented (CONTRIBUTING.md / PR template), ideally with simple
examples for newer contributors (e.g. when to squash, how to add trailers).
On Tue, Feb 3, 2026 at 8:17 AM Aman Mittal <am...@gmail.com>
wrote:
> 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, <am...@mifos.org> 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.
>>
>
Re: one commit per PR
Posted by Aman Mittal <am...@gmail.com>.
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, <am...@mifos.org> 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.
>
Re: one commit per PR
Posted by Adam Monsen <am...@mifos.org>.
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.
Re: one commit per PR
Posted by Edward Kang <ed...@gmail.com>.
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 <am...@mifos.org> 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 <ad...@gmail.com> 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 <am...@mifos.org> 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
edward.kang12@gmail.com
972-768-6940
Re: one commit per PR
Posted by Adam Monsen <am...@mifos.org>.
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 <ad...@gmail.com> 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 <am...@mifos.org> 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>
> .
>
>
>
Re: one commit per PR
Posted by Adam Monsen <am...@mifos.org>.
Thanks for your input, Nidhi! Yeah git is very powerful for crafting
patches. I commit often and I use `git commit --amend` often (and in other
projects I keep most all temporary commits around so I can retrace my steps
later). Note that while you're working on a branch feel free to make as
many commits as you want, just squash it before you mark your PR ready for
review. And yeah, once we settle some rules/tips we can document them.
On Mon, Feb 2, 2026 at 11:02 AM Nidhi Bhawari <ni...@gmail.com>
wrote:
> Hi everyone,
> As a new contributor, I agree that documenting this decision in
> CONTRIBUTING.md would be very helpful.
>
> I recently learned to use `git commit --amend` to keep my PR history
> clean. If the community decides to stick to the "one commit" rule, having
> clear examples in the documentation on how to use "Trailers" (like
> Co-authored-by: or Tested-by:) would be great. This way, new contributors
> like me can ensure we keep the history clean while still giving proper
> credit to reviewers and testers.
>
> Regards,
> Nidhi
>
Re: one commit per PR
Posted by Nidhi Bhawari <ni...@gmail.com>.
Hi everyone,
As a new contributor, I agree that documenting this decision in
CONTRIBUTING.md would be very helpful.
I recently learned to use `git commit --amend` to keep my PR history clean.
If the community decides to stick to the "one commit" rule, having clear
examples in the documentation on how to use "Trailers" (like
Co-authored-by: or Tested-by:) would be great. This way, new contributors
like me can ensure we keep the history clean while still giving proper
credit to reviewers and testers.
Regards,
Nidhi
On Tue, Feb 3, 2026 at 12:13 AM Ádám Sághy <ad...@gmail.com> 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 <am...@mifos.org> 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>
> .
>
>
>
Re: one commit per PR
Posted by Ádám Sághy <ad...@gmail.com>.
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 <am...@mifos.org> 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>.