Hi Nicolas,your are correct, I checked the history again and this seems to work fine, using the committed date for the history. Thank you for the explanation.
While checking I found another thing which confuses me: there are commits in the history which seem not to be from an OFBiz committer (hope I did not miss anything here).
Please see the screenshot here: https://share.ecomify.de/download.php?id=3&token=4dmjDN050Jz1q0I1uvI4foUdW8ZhxnTT
Looks like commits from another branch, see the non-linear history. Maybe Jacques has an explanation for it?
Thanks, Michael Brohl ecomify GmbH - www.ecomify.de Am 13.02.20 um 10:40 schrieb Nicolas Malin:
Hi, On 13/02/2020 08:03, Michael Brohl wrote:There is one drawback with PR's I just noticed: the commits of the pull requests will be written to the commit history using the timestamp of the original commits. So if the commits were written a month ago and a committer merges in the codebase now, it appears in the history a month ago.Michael, you have an example of this case ? Normally, when you merge or cherry pick, we have two dates, author date (commit origin) and the commit date. If I check the git history with the last Jacques's commit by PR I found : $ git log --pretty=fuller -n1 e1e1a4813d05f236ea851c729d3b01f5c2ff44a4 commit e1e1a4813d05f236ea851c729d3b01f5c2ff44a4 (HEAD -> trunk, origin/trunk, origin/HEAD) Author: Pierre Smits <[email protected]> AuthorDate: Tue Feb 11 10:24:10 2020 +0100 Commit: Jacques Le Roux <[email protected]> CommitDate: Wed Feb 12 12:09:34 2020 +0100 By default, the author date is displaying and the commit date is use to ordering. NicolasThis might be confusing, at least when retracing problems or following changes. Michael Brohl ecomify GmbH - www.ecomify.de Michael Brohl Geschäftsführer Fon +49 521 448 157-91 Fax +49 521 448 157-99 Mobil +49 160 3664918 Xing xing.com/profile/Michael_Brohl LinkedIn linkedin.com/in/michaelbrohl Company and Management Headquarters: ecomify GmbH, Gustav-Winkler-Str. 22, 33699 Bielefeld, Deutschland Fon: +49 521 448157-90, Fax: +49 521 448157-99, www.ecomify.de Court Registration: Amtsgericht Bielefeld HRB 41683 Chief Executive Officer: Martin Becker, Michael Brohl Am 30.01.20 um 14:25 schrieb Pierre Smits:Hi All, Recently we saw some postings in various threads how to deal with commits from contributors coming via pull requests in Github. If I understand it correctly, the issue we're dealing with has to do with the commit message (as defined in https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+commit+message+template ). After a code contribution has been accepted by a committer, this commit message appears in: 1. the OFBiz repo 2. a posting to the commit@ mailing list 3. in the referenced JIRA ticket (as a comment, and in the commit section, see e.g. https://issues.apache.org/jira/browse/OFBIZ-10954) Elements of the commit message are also used in the regularly occurring blog posts of the project. With our repositories available via Github, we can expect that more and more contributors work within their local clones, and publish their code changes (commits) in their own public forks on Github and from there issue a pull request to get these contributions evaluated by community members and when good incorporated into the OFBiz repositories. A pull request can contain one or more commits (from the contributor - or in git parlance: the author). So, when the commit message by the contributor (author) of each of his commits is formatted in accordance with the commit-message template there is nothing that stands in the way to take it to the next step. Which is the evaluation of the contribution by other community members. Is my assessment so far correct? Best regards, Pierre Smits *Apache Trafodion <https://trafodion.apache.org>, Vice President* *Apache Directory <https://directory.apache.org>, PMC Member* Apache Incubator <https://incubator.apache.org>, committer *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges) since 2008* Apache Steve <https://steve.apache.org>, committer
smime.p7s
Description: S/MIME Cryptographic Signature
