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

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

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. 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.

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