On 11/07/2015 12:24 AM, Junio C Hamano wrote: > Junio C Hamano <gits...@pobox.com> writes: > >> Michael Haggerty <mhag...@alum.mit.edu> writes: >> >>> [...] And then, if you are also OK with the >>> new subdirectory introduced in this patch series, David and I seem to be >>> in agreement that it is ready to go. It would be great if this patch >>> series could be merged in a timely manner, as it will conflict with >>> nearly any other changes that people might want to undertake in the refs >>> code. >> >> Thanks for working well together. Let me see what I can do today... > > What I'll push out later today merges this to the tip of 'pu'. > The resolution is the same for 'jch' or 'next' (I checked). > > I have to say that the merge of this topioc is not pretty. [...]
I hate to cause the maintainer extra work. I guess I was making two naive assumptions: * If we make the code-movement series simple and "obviously correct" enough, then it could be merged pretty much straight through to master. * If one or two topics conflict with the code movement, they could be one-time rebased on top of the new master (I would be willing to do this work). Maybe neither of these assumptions is valid. And maybe the correctness of our series in its current form isn't quite obvious enough. David and I will be the ones who benefit most from having this resolved quickly, because there is lots more work that has to be done after the code movement and it is kindof hard to continue that work while this topic is up in the air. I can see a few ways that we could make our series even more straightforward: 1. Leave refs.c in its original location (as suggested by Junio). Optionally, it could be moved at a later date when this area is quiescent. 2. Move content selectively from refs.c to refs/files-backend.c rather than moving the whole file there and then moving content selectively back to refs/refs.c. 3. Separate *all* of the non-obvious changes into a preparatory patch series, to be followed by a separate patch series that *only* moves code. The first idea would be a couple of hours of work (including adjusting comments and commit messages). The second and third ideas would probably best be done in combination, and might take a day or two of work because they involve reordering patches. Let us know what you think. Michael -- Michael Haggerty mhag...@alum.mit.edu -- 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
