On 3 February 2011 10:46, Eugene Sajine <euguess@xxxxxxxxx> wrote: > On Thu, Feb 3, 2011 at 1:16 AM, Nicolas Pitre <nico@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx >> 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.) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html