I am happy we are having this conversation because, once finalized, we will optimize our usage of Git (and GitHub)!
On this topic, I like the workflow and the documentation provided by one of the other Apache project, RocketQM: https://rocketmq.apache.org/docs/pull-request/ In my opinion we could follow a similar approach and provide similar documentation to our contributors and committers. Jacopo On Thu, Jan 30, 2020 at 5:10 PM Michael Brohl <michael.br...@ecomify.de> wrote: > I mean squashing in the sense of pulling several commits together in a > single commit (with a quality commit message). This could also be a diff > which is applied as a patch manually. I am not just referring to the > GitHub function. > > I really don't want to see all kinds of exotic messages coming up in our > commit history. > > If the workflow allows rejecting a pull request because of bad commit > messages or maybe a hundred commits for a change, I would also be fine > with it. > > My main point is that I'm a bit worried about quality because it is much > easier to pull in a pull request instead of applying a patch. > > Applying a patch also results in a single commit and the committer can > handle the message while a pull request maybe results in several commits > each with its own message which are in the hands of the contributor. > Applying a patch and changing things where necessary is also easier > because you can clearly see the changed files in your sandbox ("your > slightly midified patch is in trunk r..."). > > If I am not wrong, accepting a pull request does a forward merge > directly so you have to find the locations again where you want to make > changes. > > I guess reverting will also be more difficult if the pull request > contains more than one commit. > > It *could* be reasonable to request single commit pull requests to avoid > all this, leaving the work to "squash" and write quality commit messages > up to the contributor. > > I am not against using PR's but I also worry about the downsides and > additional work for contributors dealing with them. > > Thanks, > > Michael Brohl > > ecomify GmbH - www.ecomify.de > > > Am 30.01.20 um 16:33 schrieb Jacques Le Roux: > > At 1st glance, based on my experience with squashing I tend to agree > > > > Jacques > > > > Le 30/01/2020 à 16:04, Pierre Smits a écrit : > >> Having 'quality commit message' should not pose a problem when > >> contributors > >> (authors) apply the template for their commit message. > >> > >> See as an example the messages of the commit I have in pull request > >> #2 in > >> ofbiz-plugins (https://github.com/apache/ofbiz-plugins/pull/2). > >> > >> The question is whether a commit message like in > >> https://github.com/apache/ofbiz-plugins/pull/1 would be rejected. > >> > >> AFAIUI, the issue with squashing commits is, when they are shared with > >> others, that history will be rewritten and thus causing trouble for the > >> other parties. > >> IMO, squashing should not occur when a pull request has been issued. > >> > >> > >> 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 > >> > >> > >> On Thu, Jan 30, 2020 at 3:42 PM Michael Brohl <michael.br...@ecomify.de > > > >> wrote: > >> > >>> Just a quick thought because I currently cannot dig deeper: > >>> > >>> We should also have a workflow (or better: requirement) to either write > >>> quality commit messages for every commit or squash changes and have a > >>> quality commit message for the resulting commit. If people do a lot of > >>> commits during their work on a change, we might not want to have all > >>> these commits in our project history. > >>> > >>> Regards, > >>> > >>> Michael Brohl > >>> > >>> ecomify GmbH - www.ecomify.de > >>> > >>> > >>> 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 > >>>> > >>> > >
