Re: [RFC/PATCH 0/3] Thinning the git toplevel directory
- From
Nicolas Pitre <nico@fluxnic.net>
- Date
- Feb 24, 2011, 18:04 UTC
- Message-ID
- <alpine.LFD.2.00.1102241252000.26358@xanadu.home>
- In-Reply-To
- <1298567455.19041.39.camel@drew-northup.unet.maine.edu>
On Thu, 24 Feb 2011, Drew Northup wrote:
Show 19 quoted lines
> > 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).
Show 5 quoted lines
> 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