Michael Haggerty <mhag...@alum.mit.edu> writes: > 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.
It is sometimes necessary to declare "This is important, and it is solid enough. Let's fast-track it. Other people must work on top of this." and make a project-wide decision to do so. It was just that was not doable within the time I had before I had to hand the tree off. You can still work with the other people involved (Lukas as the ref-is-hidden topic contributor and Peff as the interim maintainer) to make it happen, and I wouldn't be upset. > 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. 4. Move everything in the series as-is, *BUT* in each patch where the series moved things to refs/refs.c from refs/files-backend.c, move that back to refs.c instead. No refs/refs.c anywhere in the history or in the endgame. I think having refs.h and refs.c at the toplevel for the public interface, with refs/ hierarchy holding backend specifics, would be a good organization for the endgame regardless of the conflicts with in-flight topics, and 4. achieves that. Perhaps you meant the same thing as your 1. As to the reordering of functions and structure defs, I am reasonably sure that the order in the final refs/refs.c in your series would be better thought-out than in the original refs.c, so the "reorder stuff in refs.c" can be the first step before everything is moved to refs/files-backend.c, perhaps? Thanks. -- 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
