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