Hi. Le dim. 5 juil. 2020 à 21:26, Xeno Amess <xenoam...@gmail.com> a écrit : > > @Gilles > If you want a good commit message you should define good first.
I did provide some hints, in the first post. And others have given additional suggestions. > And you should understand everybody is using what he think the best style > in commit logs. This project is team work, and newcomers should either adapt to the current style or indicate their wish for change and convince the team that it would be an improvement. > (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, The Commons project has existed for more than 15 years, and the history of the repositories is the best resource for the current style. By spending a few minutes perusing through the commit logs, a new contributor can obtain a pretty good image of how to comment the various types of changes. > then pin it > into CONTRIBUTION.md. That would be a welcome contribution: A way a new contributor can transfer informal knowledge into a formal document (that is itself related to a relatively new way of contributing). > > IMO the style you using is too short. And should contain more details. More details are fine, of course. > 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? As said above, be free to add details; but a message akin to "fix code" is just useless. > 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. If you want to spend more time writing log messages, all the better. My point is that a terse message could be sufficient to convey that the change was trivial and similar to many other such changes which the same contributor has done over the years, which the reviewer can probably trust from past reviews > However, if you passed a ruleset or law or something about this, and pin it > to CONTRIBUTION.md，then I will try to follow. See above. Thanks, Gilles > > 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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
