On Thu, 2011-02-24 at 14:08 -0500, Jeff King wrote: > 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 I am glad to hear that is the case here. Pretty much everything else I've ever worked on absolutely breaks if files are moved around and Makefiles are not updated to suit. -- -Drew Northup ________________________________________________ "As opposed to vegetable or mineral error?" -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- 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