Up to high-teens in this 43 patch series, the changes all looked "separate filesystem backend specific part from refs.c to refs-be-files.c" without other questionable changes, but I have to give up at this step for now, as conflicts between the patch and the current codebase is getting a bit too much to manually adjust the patch only to make sure there is no funnies other than a straight rename of static functions going on. We seem to have added a few more iterators in refs.c that would need to be also wrapped as methods, so this step would need to be redone. Regarding [03/43], it is a straight rename without any content change, so you probably could have done "format-patch -M". But that original commit, if I am not mistaken, left an empty ref.c instead of removing, which was somewhat funny (and Makefile still expects refs.o can be produced from refs.c). The other side of the same coin is that [04/43] expects an empty refs.c to be in the original; it should be creating a new file instead. Just for future reference to others, what I did was: * looked at the gzipped patch and made sure the preimage of refs.c and the postimage of refs-be-files.c were identical. * started from the tip of current master, merged the topics mentioned in the message with the gzipped patch to it, and called the result $BASE0. * applied 01/43 and 02/43 on $BASE0. * then manually moved refs.c to refs-be-files.c and told git about them, and applied changes to Makefile in 03/43, and committed the result. * adjusted 04/43 to expect refs.c to be missing and applied it. * continued to apply from 05/43 thru until I get a conflict that I feel uncomfortable to adjust myself. * "git format-patch --stdout -M $BASE0.. >./+dt0". * Pick 'next', 'jch' and 'pu' as the starting point, attempted to run "git am ./+dt0" (with success). At least, by adjusting for 03/43 and 04/43 and recording 03/43 as a rename in "./+dt0", the early parts of these attempts were survivable ;-). Then attempted to apply 20/43 on top of the result, all of which unfortunately left a conflict that I feel uncomfortable to adjust myself. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html