On Thu, 24 Feb 2011, Drew Northup wrote: > > On Wed, 2011-02-23 at 19:14 -0500, Nicolas Pitre wrote: > > On Wed, 23 Feb 2011, Drew Northup wrote: > > > > > Besides, if we move anything around into a deeper directory structure we > > > are inevitably going to have to deal with more recursive make problems. > > > We can't just commit to master a tree that has everything moved about > > > and get around to dealing with the Makefiles later. > > > > The initial set of patches simply moved files into subdirectories and > > made the corresponding renames within the Makefile. > > > > Reorganizing the Makefile into a better Makefile or sub-makefiles can be > > done subsequently. That's my point. > > 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). > As for making an authoritative publicly available branch containing this > reorganization work (due solely to the extreme effect it will have on > other development), I will leave it an open question as to whether this > belongs in pu while a 1.7.5 release is still a possibility. It looks > like a headache either way. Oh sure. But if we the developers of Git can't deal with that ourselves then it is a really good sign that our own tool is crappy in that area and probably needs to be improved. Such a tree reorganization is something that happens in other projects as well, so it is a good opportunity to improve Git to cope well with such a situation if it isn't up to it yet. Nicolas -- 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