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

[Hilco Wijbenga <hilco.wijbenga@gmail.com>]

On 3 February 2011 10:46, Eugene Sajine <euguess@gmail.com> wrote:
> On Thu, Feb 3, 2011 at 1:16 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
>> On Tue, 1 Feb 2011, George Spelvin wrote:
>>
>>> 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.
>>
>>> Having to type "src/" a lot more often is definitely a downside.
>>
>> Come on.  This is a rather egocentric argument without much substance.
>>
>>> 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.
>>
>>> 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.)