« first day  last day (1 day later) » 

00:12
I think that might be where a lot of people (including me) have a different idea about refactoring — it is about commits. It is about making some progress that won't go stale in some topic branch if you get pulled away. It's about integrating that work with other people's work in case it causes problems.
Refactoring is a little picture activity done with the bigger picture in mind, but the intent is for that little picture change (that one commit) to get merged in with the possibility that the bigger picture never comes to fruition. You at least leave the application in a little better state than when you started.
And sometimes people just need to see a smaller pull request to review something. There's always that, too.
While I see your point — refactoring doesn't happen in a vacuum — you also cannot define that little picture activity in terms of the bigger picture. This is one of those rare cases where you do need to focus on the little picture.
I think "big picture" your could say that the net effect is that the refactoring didn't happen, but in the moment where you are evolving the application structure in a backwards compatible way, you are refactoring; that is what I am saying, and why your question got a down-vote.
@GregBurghardt Have been with you until "cannot define" if there is no place for the small change in the large picture, why do said small change?
Otherwise, I think your answer is bang on what the OP needs.
Let me rephrase...
Even if the end result of implementing a feature means it looks as if refactoring never happened, that doesn't mean it didn't happen. It might have been the first in a series of 5 commits, but at some point it did happen.
As an illustration, imagine if I asserted that digging holes never happens, because you ultimately fill it with something like gravel, cement, or sand. But at some point you had a hole in the ground before you filled it.
That's the perspective I'm taking on "refactoring doesn't exist."
@GregBurghardt I see what you mean. But the process as a whole is not a refactoring here. It is just "getting things done". Then post is installed, cement holds the post. Job is done. There is no refactoring, just normal implementation.
The hole might be a part of the process, but my point is that it is not an important enough part to be considered separately.
I do not argue about presence of a commit, I argue about unit of work.
Or scope of a task in general.
Anyway, my wording turned out to be excessively dramatic, causing misunderstandings. We have enough mutual understanding that it is not really important.
Thank you for clarification.

« first day  last day (1 day later) »