Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes: > A patch changing a symlink into a file is written with 2 sections (in > the code, represented as "struct patch"): firstly, the deletion of the > symlink, and secondly, the creation of the file. When applying that > patch with -R, the sections are reversed, so we get: > > (1) creation of a symlink, then > (2) deletion of a file. Good observation. But I have to wonder if it breaks the support for (arguably outside the Git usecase) input that has more than one patch that touches the same path to blindly reverse the order of all patches (instead of the obvious implementation of the fix for the above stated problem --- i.e. make sure the first patch is a deletion of a symlink and what immediately follows is a creation of a regular file, and swap them only in such a case).
