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