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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > 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 < > [email protected]> 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 <[email protected]> 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 <[email protected]> > 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, <[email protected]> wrote: > > Hi Edward! Thanks for your comments. Replies inline, below. > > > > I did a bit of research... > > Fascinating. I've never used autosquash and I don't understand that > example. Based on the git-rebase(1) manpage it seems to be a way to avoid > an interactive rebase with carefully worded commit messages. Personally I'm > a big fan of interactive rebase so I probably wouldn't use it. I guess > folks can squash however they want. > > > > The multiple contributors does complicate the FINERACT-2462 > implementation... > > Thanks for this. I'm wary of adding more dependencies on github. I've > seen this codebase migrate between version control systems (from subversion > to git) and between code collaboration platforms (sourceforge to github), > and I imagine it'll happen again someday. Vendor lock-in complicates > migrations. I'm also wary of adding any friction to contributors trying to > submit patches (e.g. confirming correct email is being used). > > > > I was wondering if recording all contributors is something we can > implement automatically... > > I like this idea. Maybe it would work with the "trailers" idea? I think, > before we automate, the important first step here is reviewing what data we > currently have and gathering the new data we want while adding as little > friction as possible, and with just enough structure that we can pull out > something useful later. > > > > We have standard committer and author fields for commits, and extra data > captured by github during the PR process that is collated into all the > contributors when release notes are generated. If we can think of ways to > leverage that and write less or no code, that's even better. Could you come > up with conventions for our commit log messages, including trailers? The > commit could be force-pushed anytime before the PR is merged. > > > > > > -- > > Edward E. Kang > > [email protected] > > 972-768-6940 > > > > > > -- > > Edward E. Kang > > [email protected] > > 972-768-6940 > > > > > > -- > > Edward E. Kang > > [email protected] > > 972-768-6940 > > -- Edward E. Kang [email protected] 972-768-6940
