Hi Jacques, I don't know what to say. What I understand is that you don't want to use the template that committers are now abiding by and which you agreed on yourself before saying "I changed my mind"! I don't remember having any discussion beyond a few complaints inside your own commit messages.
There are numerous ways to setup your environment so you can commit more easily, but it's hard to say how exactly for each committer's operating system and set of tools. But I think it's not difficult with a proof being that committers were getting things nicely committed during the community day which had lots of commits. The easiest part of committing code is the commit message, the hard work is in checking that the patch is correct, and that all tests pass, and that quality is good etc. So committing a lot without a good review is perhaps detrimental to the code base, and if you commit so much and so fast that you don't have time to add a few characters, words or new lines here and there then that might indicate you're rushing, which might affect the quality of your commits. Anyway, I won't dwell more on this subject, it seems you already took a decision. Taher Alkhateeb On Sun, Sep 18, 2016 at 8:33 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Le 18/09/2016 à 17:48, Taher Alkhateeb a écrit : > >> Sure let's add reverts, but can we also agree on a unified format? I still >> see Jacques using present and others using past which makes the original >> purpose of the unification unattainable (to automate reports). >> > > "(to automate reports)" :-o Are you kidding? > We know it's (or should be) the 1st word on the 1st line before the 1st > semicolon > Can't we use a regexp to parse on a token like eg "fix" for "Fixed, Fixes, > Fix for". Note that the last is normally the "norm" > Can't we really do what GitHub is doing in a similar case: > https://help.github.com/articles/closing-issues-via-commit-messages/ > I already offered my help multiple times but not even got an answer about > my questions :/ > > Same for the parentheses around the Jira number they are superfluous. I > see no reasons to put them there but finally unwillingly did :/ > We know it's only (a) number/s (in case of multiple issues separated by a > white space) on the second line preceded by an "OFBIZ-" string nothing hard > to parse > > I also see >> different levels of support for text width from different committers >> > > I honestly thought this could help, but Jacopo disagreed > http://markmail.org/message/twr7adj7wefz4dng > Anyway I did not yet get any answer from TortoiseSvn and did not find a > way to have that automated in Eclipse commit feature (yes I commit a lot :p) > Do you have something easy to propose? > > Thanks > > Jacques > > > >> On Sun, Sep 18, 2016 at 6:41 PM, Michael Brohl <michael.br...@ecomify.de> >> wrote: >> >> +1 >>> >>> Michael >>> >>> >>> Am 18.09.16 um 11:19 schrieb Jacques Le Roux: >>> >>> Hi, >>> >>>> In some cases we need to revert a commit done for a Jira after we >>>> discover it causes an issue. We have not yet other means that using the >>>> fix >>>> word. >>>> I suggest we put in the "Reverts" (or "Revert for" or "Reverted" as it >>>> please you) word in the commit template for this reason. >>>> Because it's a different thing than really fixing the initial issue >>>> reported in the Jira but it's sill related to it >>>> >>>> What do you think? >>>> >>>> Jacques >>>> >>>> >>>> >>> >
