Thinking about this a little bit more, I am not sure what would change in practice if we introduced such a policy (of adding messages to merge commits). We are not automatically enforcing the current format of commit messages so why is it a problem we would not enforce the format of commit messages in the merge commits? I can not be worse than it currently is. If we now say what a commit message should look like for "normal" commits, why would it be any different on merge commits?
On Thu, 18 Aug 2022 at 16:46, Josh McKenzie <jmcken...@apache.org> wrote: > > this should be pretty easy to incorporate into the workflow? > > The hard part isn't incorporating this into one's workflow, the hard part is > getting all of us to agree that this is something we should all do and > formalize it as our project process. :) > > On Thu, Aug 18, 2022, at 10:41 AM, Stefan Miklosovic wrote: > > 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. > >
