Re: [1.8.0] reorganize the mess that the source tree has become

On 3 February 2011 10:46, Eugene Sajine [off-list ref] wrote:

On Thu, Feb 3, 2011 at 1:16 AM, Nicolas Pitre [off-list ref] wrote:

quoted

On Tue, 1 Feb 2011, George Spelvin wrote:

quoted

For what it's worth, I don't see the "cleanup".

If it significantly reduced the size of the largest directory,
that would be a win.  But moving everything into src/ doesn't
do that.

If there's a way to divide the source into cohesive subunits, that
would be great.  A programmer could ignore whole subdirectories
when working on something.

But just moving the whole existing pile into a subdirectory "because
everyone else does it" is not a reason; that's superstition.

There is no superstition here, simply basic elegance.

When you pick up a book from a shelf, do you see the actual content of
the book printed right from the inside of the cover page, and the table
of content tossed in the margin?  Would you construct a book yourself
that way?

A nice source tree should be organized with a minimum of hierarchical
structure.  To a newbie wanting to contribute to Git, it is rather
frightening to cd into the git directory and see that ls generates more
than 280 entries.  That simply looks sloppy.  And this gets much worse
after a make.

The top directory should make different things stand out much more
clearly, like a preface and a table of content.  You have the
documentation here, the source there, the tests there, a clearly visible
README file, etc.  If the src directory has about the same relative
number of files after a move that's fine.  At least you should expect
_only_ source files in there (and possibly their by-products), and not
other types of data buried into the mix.

quoted

Having to type "src/" a lot more often is definitely a downside.

Come on.  This is a rather egocentric argument without much substance.

quoted

Heck, that's one thing I actively dislike about GNU autoconf conventions.

This has _nothing_ about any autoconf convention.  GNU autoconf requires
stupid things like having a bunch of files such as CREDITS, INSTALL,
CHANGELOG, and other whatnots even if you have nothing to put in them,
in which case they still have to be there but empty.  It also dictates
the exact name your directories must have, etc.

I'm not proposing a tree reorganization because GNU autoconf commands
it, but rather because this is a sensible thing to do.

quoted

If there's a compelling reason to change, could someone please describe it?

It's about the third time I'm putting forward arguments for this.
Please see the list archive.

P.S. the netiquette on busy mailing lists recommends that you preserve
all the email addresses that were listed as recipients on the message
you reply to.  That would be highly appreciated.


Nicolas
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

I'm not a hacker, but a user who had sometimes peeked into the git
sources. Unbelievable mess... Impossible to see the structure in
command line interface.
I totally agree with Nicolas here.
Folders were invented for a reason.

IMHO
src for source code
build for build by-products
tests for tests

Come on, give us some love, please!;)

Another one from the peanut gallery. :-) I wholeheartedly agree with
both Nicolas and Eugene.

Quite frankly, I'm surprised there are (presumably experienced)
developers who do not immediately see the value of a little
organization. Surely, given the use of code conventions, formatting
rules, etcetera, the obvious one step further is to also organize
where the files go?

(Given that I'm just a lurker I promise to leave it at this. I just
wanted to show Nicolas a little support.)