Re: [RFC/PATCH 0/3] Thinning the git toplevel directory

[Drew Northup <drew.northup@maine.edu>]

On Wed, 2011-02-23 at 19:14 -0500, Nicolas Pitre wrote:
> On Wed, 23 Feb 2011, Drew Northup wrote:
> 
> > 
> > On Wed, 2011-02-23 at 12:18 -0500, Nicolas Pitre wrote:
> > > On Wed, 23 Feb 2011, Junio C Hamano wrote:
> > > 
> > > > Jeff King <peff@peff.net> writes:
> > > > 
> > > > > On Tue, Feb 22, 2011 at 11:30:41AM -0800, Junio C Hamano wrote:
> > > > >
> > > > >> > Speaking of Makefiles, one downside to all of this directory
> > > > >> > segmentation is that you can't run "make" from the subdirectories.
> > > > >> 
> > > > >> I had an impression that "make -C lib/" would be one of the goals, iow,
> > > > >> when we split the directory structure, the next step would be to split the
> > > > >> top-level Makefile so that each directory is covered by its own Makefile,
> > > > >> just like Documentation/ is already usable that way.
> > > > >
> > > > > Ugh. I am not thrilled at the prospect of more recursive make.
> > > > 
> > > > Likewise. Notice that I have consistently been unthrilled when people
> > > > started talking about splitting the source code tree?
> > > 
> > > Maybe that would be wiser to consider an initial set of patches as those 
> > > which were proposed to only do the simple file move first, then wait for 
> > > the dust to settle before doing more changes.  Doing too much in one go 
> > > is inevitably going to bounce against the human tendency to resist any 
> > > kind of change, good or bad.
> > 
> > > Nicolas
> > 
> > Nicolas,
> > They are doing it this way because change is not the objective. A
> > possible better way of managing the codebase is.
> 
> Incidentally I know that (guess whom this proposal came from initially).  ;-)
> 
> > Perhaps it isn't the
> > right way to go--and we won't know that until we've explored all of the
> > side-effects, advantages, disadvantages, etc.
> > 
> > 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. That's what I meant by "later" in my comment (as
it apparently wasn't obvious from context alone). This is especially
important for gaining the accession of the rest of the developer
community. Jeff (Peff) and Junio are both apparently quite well aware of
this--and I happen to agree with Jeff's way of approaching this type of
change.

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.

-- 
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59