Re: [All][Geometry] Commit log (Was: [GitHub] ...)
Hello. Le lun. 6 juil. 2020 à 18:52, Xeno Amess a écrit : > > Hi. > I tried to write a guide line document for this thing we discussed. > Fell free to use it in any repo you want. > And also feel free to continue the discussion, The log is written by humans for humans to read. Should it really be formalized in that way? IMO, extracting a few different examples of a good message from various repositories might be more effective in conveying the intent. Even if the formal grammar would be a first step towards writing a script for checking compliance, I'm not sure that many components would be willing to enforce it. This should probably be followed up in a new thread, in order to probe interest, before you embark on this. Gilles >> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Geometry] Commit log (Was: [GitHub] ...)
committers, they are hopefully aware >>> of how *their* project works. >>> >>> > that is another reason why you need to make it a clear rulebook >>> > about what is good commit log style in your opinions. >>> >>> The discussion is starting to go in circles. This thread already >>> contains concrete suggestions of what to do and not do, as well >>> as further reading. >>> If you think that they should be laid out in details belongs in the >>> "contributing.md" file(s), that's great, but *you* are welcome to >>> provide a PR. >>> >>> Thanks, >>> Gilles >>> >>> > >>> > Sujit Pal 于2020年7月6日周一 上午7:12写道： >>> > >>> > > 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 >>> 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 于 2020年7月6日周一 上午2:29写道： >>> > > > >>> > > > > Hi Matt. >>> > > > > >>> > > > > Le dim. 5 juil. 2020 à 13:39, Matt Juntunen >>> > > > > 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 >>> > > &
Re: [All][Geometry] Commit log (Was: [GitHub] ...)
rovide a PR. >> >> Thanks, >> Gilles >> >> > >> > Sujit Pal 于2020年7月6日周一 上午7:12写道： >> > >> > > 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 >> 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 于 2020年7月6日周一 上午2:29写道： >> > > > >> > > > > Hi Matt. >> > > > > >> > > > > Le dim. 5 juil. 2020 à 13:39, Matt Juntunen >> > > > > 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 >> > > > > > Sent: Sunday, July 5, 2020 4:00 AM >> > > > > > To: Commons Developers List >> > > > > > 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 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 >> >>
Re: [All][Geometry] Commit log (Was: [GitHub] ...)
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 > 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 于 2020年7月6日周一 上午2:29写道： > > > > > > > > > Hi Matt. > > > > > > > > > > Le dim. 5 juil. 2020 à 13:39, Matt Juntunen > > > > > 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 > > > > > > Sent: Sunday, July 5, 2020 4:00 AM > > > > > > To: Commons Developers List > > > > > > 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 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 > >
Re: [All][Geometry] Commit log (Was: [GitHub] ...)
ed. > > > 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 于 2020年7月6日周一 上午2:29写道： > > > > > > > Hi Matt. > > > > > > > > Le dim. 5 juil. 2020 à 13:39, Matt Juntunen > > > > 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 > > > > > Sent: Sunday, July 5, 2020 4:00 AM > > > > > To: Commons Developers List > > > > > 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 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
Re: [All][Geometry] Commit log (Was: [GitHub] ...)
@Gilles > 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. That is not that easy my friend. First, the commons project has existed for more than 15 years, if every normal contributor should track every commit log, that seems too much time costing. Of course I don't mean committers of that repo should not do that, I mean normal contributors. Second, what I learned from commons' repos' commit history is a total mess. I've seen repo who fails its own unit-tests in every commit after 3 hours after its creation. I've seen repo who merge quite some ci-failed prs. I've seen repo who allow people commit directly upon that repo, no need pr unless necessary. I've seen repo who do not squash commits before merge sometimes. So that is why I said, if you want good commit log, you have to formally request it, and make it clear what is good commit log style in this sub-repo. Of course a unified commit log style seems good, but commons repos are,.not that unified, so you need time/effort to persuade other committers, that is another reason why you need to make it a clear rulebook about what is good commit log style in your opinions. Sujit Pal 于2020年7月6日周一 上午7:12写道： > 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 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 于 2020年7月6日周一 上午2:29写道： > > > > > Hi Matt. > > > > > > Le dim. 5 juil. 2020 à 13:39, Matt Juntunen > > > 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 > > > > Sent: Sunday, July 5, 2020 4:00 AM > > > > To: Commons Developers List > > > > Subject: [All][Geometry] Commit log (Was: [GitHub] ...) > > > > > > > &g
Re: [All][Geometry] Commit log (Was: [GitHub] ...)
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 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 于 2020年7月6日周一 上午2:29写道： > > > Hi Matt. > > > > Le dim. 5 juil. 2020 à 13:39, Matt Juntunen > > 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 > > > Sent: Sunday, July 5, 2020 4:00 AM > > > To: Commons Developers List > > > 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 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 > > > > >
Re: [All][Geometry] Commit log (Was: [GitHub] ...)
Hi. Le dim. 5 juil. 2020 à 22:31, Gary Gregory a écrit : > > I agree with Xenos. Accepting PRs with uninformative (for short) messages is eroding what regular contributors have established over the years in order to make it possible to track the history of changes. Do you suggest that we forsake that goal? Gilles > > Gary > > On Sun, Jul 5, 2020, 15:26 Xeno Amess 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 于 2020年7月6日周一 上午2:29写道： > > > > > Hi Matt. > > > > > > Le dim. 5 juil. 2020 à 13:39, Matt Juntunen > > > 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 > > > > Sent: Sunday, July 5, 2020 4:00 AM > > > > To: Commons Developers List > > > > 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 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
Re: [All][Geometry] Commit log (Was: [GitHub] ...)
Hi. Le dim. 5 juil. 2020 à 21:26, Xeno Amess 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 于 2020年7月6日周一 上午2:29写道： > > > Hi Matt. > > > > Le dim. 5 juil. 2020 à 13:39, Matt Juntunen > > 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 > > > Sent: Sunday, July 5, 2020 4:00 AM > > > To: Commons Developers List > > > 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 s
Re: [All][Geometry] Commit log (Was: [GitHub] ...)
I agree with Xenos. Gary On Sun, Jul 5, 2020, 15:26 Xeno Amess 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 于 2020年7月6日周一 上午2:29写道： > > > Hi Matt. > > > > Le dim. 5 juil. 2020 à 13:39, Matt Juntunen > > 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 > > > Sent: Sunday, July 5, 2020 4:00 AM > > > To: Commons Developers List > > > 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 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 > > > > >
Re: [All][Geometry] Commit log (Was: [GitHub] ...)
@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 于 2020年7月6日周一 上午2:29写道： > Hi Matt. > > Le dim. 5 juil. 2020 à 13:39, Matt Juntunen > 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 > > Sent: Sunday, July 5, 2020 4:00 AM > > To: Commons Developers List > > 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 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 > >
Re: [All][Geometry] Commit log (Was: [GitHub] ...)
Hi Matt. Le dim. 5 juil. 2020 à 13:39, Matt Juntunen 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 > Sent: Sunday, July 5, 2020 4:00 AM > To: Commons Developers List > 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 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
Re: [All][Geometry] Commit log (Was: [GitHub] ...)
It's ok IMO to say "Add Javadoc" vs. "Fix Javadoc" vs. "Expand Javadoc". Plain "Javadoc" is ok if terse. I like the format of the first line standing on its own as a sentence. Then there can be a blank line followed by details. That first line can be a JIRA title. For example, excluding the "---" --- [TEXT-178] The foo does not flibber the widget. Add a disabled test. --- Think about what you are saying in a commit comment helps maintainers. Think about what belongs in a commit comment vs in code comments or Javadoc. Gary On Sun, Jul 5, 2020, 04:00 Gilles Sadowski wrote: > 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 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 > >
Re: [All][Geometry] Commit log (Was: [GitHub] ...)
Here is an excellent blog post summarizing what makes good commit messages: https://chris.beams.io/posts/git-commit/ On Sun, Jul 5, 2020 at 7:38 AM Matt Juntunen wrote: > Yes, I should have modified that commit message to indicate that the > change was warranted. > -Matt > > From: Gilles Sadowski > Sent: Sunday, July 5, 2020 4:00 AM > To: Commons Developers List > 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 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 > > -- == Melloware melloware...@gmail.com http://melloware.com ==
Re: [All][Geometry] Commit log (Was: [GitHub] ...)
IMO, the log message serves the following main purposes: - explains why the change was made, so reviewers can properly check that the diff agrees - identifies the change in the historical log so it can be found easily Information necessary to understand the code should be added to the source, not the log message. It should not be necessary to read the log in order to understand the code -- we don't provide logs with the source. It's not always easy to get the balance right... On Sun, 5 Jul 2020 at 12:39, Matt Juntunen wrote: > > Yes, I should have modified that commit message to indicate that the change > was warranted. > -Matt > > From: Gilles Sadowski > Sent: Sunday, July 5, 2020 4:00 AM > To: Commons Developers List > 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 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
Re: [All][Geometry] Commit log (Was: [GitHub] ...)
Yes, I should have modified that commit message to indicate that the change was warranted. -Matt From: Gilles Sadowski Sent: Sunday, July 5, 2020 4:00 AM To: Commons Developers List 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 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
[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 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
