On Tue, Dec 15, 2020 at 10:53 PM David Gow <davidgow@xxxxxxxxxx> wrote:
>
> I know the original patchset did have an issue (with one of the other
> patches) that Andrew fixed while merging, so maybe it snuck through
> while that was happening.
Yeah, I suspect it happened when Andrew was shuffling things around.
And it's probably partly due to the fact that the patches themselves
are _really_ hard to actually read, because all the real changes are
hidden by the huge patches to remove and add files.
When you have 1600 lines of patch, it's really easy to get "patch
blind" and miss the small patch fragments that change the Makefile or
Kconfig file etc.
Back in the days when we worked almost exclusively with patches (ie
before BK and git), we had very high barriers for renaming files
partly for this exact reason. Renames as patches are just _so_ hard
to read. It's almost completely impossible to see if it's a pure
rename of if something else also changed, when you have one big hunk
that completely removes one file, and another big hunk that completely
adds a new one.
Of course, patch conflicts when there are changes to the files also
then make renames a huge pain in that situation.
With git, we've been *much* more open to file renames, because git
itself handles at least the usual simple cases of merge conflicts
automatically for us, and follows renames etc. And the git diff
extension to actually show renames as renames in a diff make it a
*lot* easier to see what a rename patch actually does.
But as long as renames are treated as patches, I'm going to go back to
the old rules that were "we never rename a file unless there is some
absolutely massive critical reason to do so".
Linus
