/* Squash merge the 'dev' branch onto master. The change on master
will include both the original PR and your coding style fixes. Again,
this assumes you are the only user of dev and another reason to
consider using a custom temporary branch./
Thank you for sharing this step-by-step process. I think it is fine,
we will always push the commits the dev branch and only when
everything is tested and stable it should be moved to the master.
Actually, I think I recommended (through implication) that we should not
use the 'dev' branch, but rather a custom, per-PR branch. A single dev
branch does not work for the reasons I mention above. The worst is that
many people are using the dev you cannot squash merge a change onto master.
Perhaps we could squash merge from a custom branch to the dev branch,
but that was not the suggested workflow.
And the changes would be moved to master with no testing. No one is
doing any manual testing and there is no purpose in maintaining
potentially hundreds of changes on individual branches. It does not
serve either the project or the user.
In the future we could have some automated test to run nxstyle and
flag the PR as complaint before we review it. Projects using gerrit
automatically validates whether the patch could be applied and whether
it will break the build or not. Then the contributor needs to send a
fine patch before it be reviewed.
The workflow will be improved in the future, but any interim workflow
will be the same flawed workflow that was used in the Bitbucket
repositories.. with some tweaks for working together better.
Greg
