Strategy to deal with automatic formatting, given the potential to create messy conflicts in active branches

USE CASE: WHAT DO YOU WANT TO DO?

Start using the automatic formatting in the change procedure.

STEPS TO REPRODUCE AN ISSUE (OR TRIGGER A NEW FEATURE)

Before branching, but after pulling master & checking that no-one is working on the files you intend to edit, run the automatic formatter on the master branch
After changes are done on files on which the formatter had been run in step 1, run it again before each commit of those files
Instead of running the formatter as is described in the current procedure, run the formatter on master for any files that were additionally edited after merging the PR

CURRENT BEHAVIOR

In order to avoid conflicts in active branches, we have not been running the automatic formatting and instead have been waiting until all active branches are merged before doing automatic formatting. In instances where formatting was done during branch work, real changes become buried among formatting changes, causing reviewers to go to individual commits to do reviews. This is problematic for various reasons, mainly due to inflexibility of bitbucket's PR interface.

EXPECTED BEHAVIOR

Temporarily adjust the auto-formatting step(s) in the change procedure to do formatting on specific files directly in master. Level of effort is trivial, thus commits directly to master are allowed. This will make reviews much easier.

DEVELOPERS ONLY SECTION

SUGGESTED CHANGE (Pseudocode optional)

See expected behavior above.

FILES AFFECTED (where the changes will be implemented) - developers only

SCMP_TreeView3.doc, section 3.2.1 CHANGE CONTROL OVERVIEW PROCEDURE
SCMP_TreeView3.doc, section 3.2.6.2.2 MERGE REQUEST PROCEDURE

LEVEL OF EFFORT - developers only

minor

COMMENTS

Comments (3)