On Thu, Feb 24, 2011 at 01:04:21PM -0500, Nicolas Pitre wrote: > > It can be done as a separate patch, but it should all be done in the > > public branch (pu?) as atomically as possible (one merge from Junio's > > workspace). In other words, the public branch should never fail to build > > because of this work. > > Who said this would fail to compile? > > If you move bar.c into the foo directory, then in the existing Makefile > you simply have to make a mechanical rename of bar.c to foo/bar.c. > Restructuring the Makefile can be done separately from the file move > without ever breaking the build (except for unintentional mistakes of > course). Exactly. Maybe it wasn't clear in the previous bits of the thread, but Makefile reorganization is a totally optional thing that can come on top of file movement if we choose. I just brought it up with file movement because having a bunch of subdirs is going to probably make us _want_ to do something with Makefiles. In the interim it may not work to run make from the "cmds" subdirectory, but that is not a "fail to build" breakage. As long as we build via "make" from the root, then there is no regression. Adding extra make fluff on top of that is feature work, not a bug fix. -Peff -- 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