Adding commit messages into merge commits for increased understanding of the codebase when you are git-blaming is the absolute minimum we can do to help you with (not only) your frustration. merging with -s ours opens up an editor where you do have a possibility to tweak the message as you wish so this should be pretty easy to incorporate into the workflow?
On Thu, 18 Aug 2022 at 16:36, Josh McKenzie <jmcken...@apache.org> wrote: > > Until IDEs auto cross-reference JIRA, > > I'm going to lightly touch the lid of Pandora's Box here and walk away > slowly. It drives me *nuts* when I'm git blaming a file to understand the > context of why a change was made (to make sure I continue to respect it!) and > I see "merge 3.11 into trunk" or some other such useless commit message, then > have to dig into the git integration and history, then figure out which merge > commits were real and which were -s ours and silently changed, etc. > > So about those merge commits... ;) > > Anyway - longer-form commit messages (that we also propagate into merge > commits and also indicate when a merge commit makes material changes to the > base branch diff) would be a large quality of life improvement as this > codebase continues to mature IMO. > > On Thu, Aug 18, 2022, at 6:55 AM, Mick Semb Wever wrote: > > That's not accurate. The ASF requires that any significant contribution > requires a i(CLA), committer or not. > > Is there any guidance in the ASF docs as to what qualifies as "significant"? > This seems like stuff we could document pretty trivially as a project and > maybe link from the PR template. > > The more we can encourage and enable folks to independently work on something > and pull the trigger on contributing to the project, the better.
