Thread (8 messages) flat view 8 messages, 4 authors, 2016-06-15

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

From: Jeff King <hidden>
Date: 2016-06-15 22:50:39

On Thu, Feb 24, 2011 at 01:04:21PM -0500, Nicolas Pitre wrote:
quoted
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).
Exactly. Maybe it wasn't clear in the previous bits of the thread, but
Makefile reorganization is a totally optional thing that can come on top
of file movement if we choose. I just brought it up with file movement
because having a bunch of subdirs is going to probably make us _want_ to
do something with Makefiles.

In the interim it may not work to run make from the "cmds" subdirectory,
but that is not a "fail to build" breakage. As long as we build via
"make" from the root, then there is no regression. Adding extra make
fluff on top of that is feature work, not a bug fix.

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help