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

On Wed, 23 Feb 2011, Drew Northup wrote:

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

quoted

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.

quoted

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.


Nicolas