On Fri, 2015-09-25 at 13:54 -0700, Junio C Hamano wrote: > 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.
Unfortunately, as long as there continue to be changes to refs.c, this will continue to be an issue. I can rebase, fix the conflicts, and re-send. Later, you say > * Pick 'next', 'jch' and 'pu' as the starting point, attempted to Do you mean that you merged these branches together, or that you tried each of the three? Which would you like me to rebase 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. Will fix in the re-roll. > 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. This was intentional. Ronnie Sahlberg's original version of this patch simply removed refs.c (without changing Makefile), which broke the build. I didn't like that. So instead I simply left an empty file. It looks like you would prefer that 03/43 move refs.c and update Makefile, then have 04/43 create a new file and update Makefile again. I'll do that instead. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
