Not a committer, just an interested observer, I got on this list because of a PR I submitted to commons-math long ago, and have stayed on since.
There is a standard for commit messages I came across recently and which our team is trying to apply to our own commit messages. Idea is to make commit messages machine parse-able with some help from humans. Thought I would share it here in case it is of interest. https://www.conventionalcommits.org/en/v1.0.0/ -sujit On Sun, Jul 5, 2020 at 12:26 PM Xeno Amess <xenoam...@gmail.com> wrote: > @Gilles > If you want a good commit message you should define good first. > And you should understand everybody is using what he think the best style > in commit logs. (at least most of the times, when they are not in hurry). > If you really want this I think you should write a guideline or rule set > for commit message style, with good examples and bad examples, then pin it > into CONTRIBUTION.md. > > IMO the style you using is too short. And should contain more details. > > for example, you said the word fix is rundantant, whitch I really cannot > agree. If you do not add a verb who will know what we do to the javadoc? > create, add，delete, fix, refine, remake,or sync? > All the verbs are possible, and they have different meanings and use cases. > When I use create or add I mean there does not exist some javadoc for > something before this pr. > When I use delete I delete some javadoc in this pr. > When I use fix I mean the original javadoc is wrong in format or meaning, > and this pr aims to fix it. > When I use refine I mean the original javadoc is correct, or at least > correct in format, but we make it better in this pr. > When I use remake I mean I redo this thing. usually not on javadoc l but > sometimes on functions. > So I do not think the verb can be deleted. > However, if you passed a ruleset or law or something about this, and pin it > to CONTRIBUTION.md，then I will try to follow. > > > > > Gilles Sadowski <gillese...@gmail.com> 于 2020年7月6日周一 上午2:29写道： > > > Hi Matt. > > > > Le dim. 5 juil. 2020 à 13:39, Matt Juntunen > > <matt.juntu...@hotmail.com> a écrit : > > > > > > Yes, I should have modified that commit message to indicate that the > > change was warranted. > > > > Thanks for the good intention, but what I'm really getting at is that > > PRs for our projects should already contain a good commit message > > (cf. advice given in the follow-up posts); suggestions, discussions, > > etc. must be directed elsewhere (ML or JIRA). > > [In particular, having to modify the commit message is a burden when > > the change is trivial; in that case, I would rather make the change and > > discard the PR...] > > > > Gilles > > > > > -Matt > > > ________________________________ > > > From: Gilles Sadowski <gillese...@gmail.com> > > > Sent: Sunday, July 5, 2020 4:00 AM > > > To: Commons Developers List <dev@commons.apache.org> > > > Subject: [All][Geometry] Commit log (Was: [GitHub] ...) > > > > > > Hello. > > > > > > I'd like to collect some opinions about enforcing a minimal form in > > > commit messages. > > > My preference is that a log message is either > > > * terse, when the commit is trivial (e.g. "Javadoc" or "Unused > > variable"), or > > > * detailed but factual, if the change is not obvious. > > > > > > IMHO, a commit message should rarely (if ever) > > > * contain redundant words (such as "fix"), > > > * be a plain rewording of a trivial change (rather that the purpose of > > > the change), > > > * make the reviewer second-guess whether the change is warranted. > > > > > > Informal and uninformative/noisy messages might seem the new normal on > > > GitHub but does that mean that we pass on them in our projects? > > > > > > Regards, > > > Gilles > > > > > > Le sam. 4 juil. 2020 à 13:48, GitBox <g...@apache.org> a écrit : > > > > > > > > > > > > darkma773r commented on pull request #88: > > > > URL: > > > https://github.com/apache/commons-geometry/pull/88#issuecomment-653756040 > > > > > > > > > > > > Merged in commit 6c90e34ff11fb9fa279d9b060abf70c14ce3cd2a > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > >
