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



Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to