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.
