Re: [PATCH 20/43] refs-be-files.c: add methods for the ref iterators

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.

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.