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

On Wed, 2011-02-23 at 12:18 -0500, Nicolas Pitre wrote:

On Wed, 23 Feb 2011, Junio C Hamano wrote:

quoted

Jeff King [off-list ref] writes:

quoted

On Tue, Feb 22, 2011 at 11:30:41AM -0800, Junio C Hamano wrote:

quoted

quoted

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