If we are concerned about the single line that can break the product,
then our testing has failed us on so many levels, that there is no hope.
But looking forward to see how long one can sustain the "factor ->
commit -> make changes required to fulfill JIRA -> commit -> manual
merge"...
Also, who reviews the refactor, because even that can introduce
unintentional bugs... same effort as single commit. In single commit, if
the refactor has made code cleaner, clearer and simpler, maybe 1 commit
is easier to follow.
Once again... mileage will vary for EVERYONE.
On 5/31/19 14:31, Jacob Barrett wrote:
On May 31, 2019, at 2:23 PM, Udo Kohlmeyer <u...@apache.org> wrote:
I must be honest, but I am yet to find 1 developer that keeps a list of all
changes they want to be refactored separate from the bug/feature code. OR
better stated I am yet to find where this was sustainable AND productive.
Challenge accepted and complete… I have done this on a few PRs recently. I have
taken to cleaning up the code first, leaving that as a separate commit on the
PR, then fixing the code in question as another commit. The trick has come when
merging the PR I wanted to squash all feedback commits. This was a manual task
outside of GitHub. Lately I have taken to filing a PR fo the area I am cleaning
up, merging that, then a PR for the fix and merging that. I haven’t decided
which I find more tedious yet.
I do know that it sucks to find the one line change buried in a 1000 line
cleanup task. They should always be separate commits into develop.
-Jake
