{"thread":{"id":"26384","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","startedAt":"2011-02-02T02:29:09Z","lastAt":"2011-02-05T15:11:43Z","messageCount":15,"participants":["George Spelvin","Erik Faye-Lund","Pascal Obry","Nicolas Pitre","Miles Bader","Andreas Schwab","Eugene Sajine","Hilco Wijbenga","Tor Arntsen","Jakub Narebski","Nicolas Sebrecht","Drew Northup"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"160248","messageId":"20110202022909.30644.qmail@science.horizon.com","threadId":"26384","inReplyTo":null,"subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"George Spelvin","fromEmail":"linux@horizon.com","sentAt":"2011-02-02T02:29:09Z","receivedAt":"2011-02-02T02:29:09Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"For what it's worth, I don't see the \"cleanup\".\n\nIf it significantly reduced the size of the largest directory,\nthat would be a win. But moving everything into src/ doesn't\ndo that.\n\nIf there's a way to divide the source into cohesive subunits, that\nwould be great. A programmer could ignore whole subdirectories\nwhen working on something.\n\nBut just moving the whole existing pile into a subdirectory \"because\neveryone else does it\" is not a reason; that's superstition.\n\nHaving to type \"src/\" a lot more often is definitely a downside.\n\nHeck, that's one thing I actively dislike about GNU autoconf conventions.\n\nIf there's a compelling reason to change, could someone please describe it?\n"},{"id":"160259","messageId":"AANLkTikBH8Qs3izT86WW7qyJ2etwFFj9GPVJ2QeRCmag@mail.gmail.com","threadId":"26384","inReplyTo":"20110202022909.30644.qmail@science.horizon.com","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2011-02-02T08:31:17Z","receivedAt":"2011-02-02T08:31:17Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Wed, Feb 2, 2011 at 3:29 AM, George Spelvin wrote:\n> If there's a compelling reason to change, could someone please describe it?\n\nI think the most compelling argument I can think of is that it makes\ntop-level entries like Documentation, RelNotes, COPYING, README and\nINSTALL easier to spot when doing \"ls\". For some users (first-time\nhackers etc) that's a pretty big plus, I'd think.\n"},{"id":"160290","messageId":"4D49B831.2030007@obry.net","threadId":"26384","inReplyTo":"AANLkTikBH8Qs3izT86WW7qyJ2etwFFj9GPVJ2QeRCmag@mail.gmail.com","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Pascal Obry","fromEmail":"pascal@obry.net","sentAt":"2011-02-02T20:01:53Z","receivedAt":"2011-02-02T20:01:53Z","isPatch":false,"sender":{"key":"pascal@obry.net","avatar":"https://avatars.githubusercontent.com/u/467069?v=4"},"body":"Le 02/02/2011 09:31, Erik Faye-Lund a écrit :\n> On Wed, Feb 2, 2011 at 3:29 AM, George Spelvin wrote:\n>> If there's a compelling reason to change, could someone please describe it?\n> \n> I think the most compelling argument I can think of is that it makes\n> top-level entries like Documentation, RelNotes, COPYING, README and\n> INSTALL easier to spot when doing \"ls\". For some users (first-time\n> hackers etc) that's a pretty big plus, I'd think.\n\nI was about to say that too. That's an argument strong enough I would\nsay. Today it is hard to see the structure.\n\n-- \n\n--|------------------------------------------------------\n--| Pascal Obry Team-Ada Member\n--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE\n--|------------------------------------------------------\n--| http://www.obry.net - http://v2p.fr.eu.org\n--| \"The best way to travel is by means of imagination\"\n--|\n--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B\n"},{"id":"160315","messageId":"alpine.LFD.2.00.1102030036420.12104@xanadu.home","threadId":"26384","inReplyTo":"20110202022909.30644.qmail@science.horizon.com","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2011-02-03T06:16:10Z","receivedAt":"2011-02-03T06:16:10Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 1 Feb 2011, George Spelvin wrote:\n\n> For what it's worth, I don't see the \"cleanup\".\n> \n> If it significantly reduced the size of the largest directory,\n> that would be a win. But moving everything into src/ doesn't\n> do that.\n> \n> If there's a way to divide the source into cohesive subunits, that\n> would be great. A programmer could ignore whole subdirectories\n> when working on something.\n> \n> But just moving the whole existing pile into a subdirectory \"because\n> everyone else does it\" is not a reason; that's superstition.\n\nThere is no superstition here, simply basic elegance.\n\nWhen you pick up a book from a shelf, do you see the actual content of \nthe book printed right from the inside of the cover page, and the table \nof content tossed in the margin? Would you construct a book yourself \nthat way?\n\nA nice source tree should be organized with a minimum of hierarchical \nstructure. To a newbie wanting to contribute to Git, it is rather \nfrightening to cd into the git directory and see that ls generates more \nthan 280 entries. That simply looks sloppy. And this gets much worse \nafter a make.\n\nThe top directory should make different things stand out much more \nclearly, like a preface and a table of content. You have the \ndocumentation here, the source there, the tests there, a clearly visible \nREADME file, etc. If the src directory has about the same relative \nnumber of files after a move that's fine. At least you should expect \n_only_ source files in there (and possibly their by-products), and not \nother types of data buried into the mix.\n\n> Having to type \"src/\" a lot more often is definitely a downside.\n\nCome on. This is a rather egocentric argument without much substance.\n\n> Heck, that's one thing I actively dislike about GNU autoconf conventions.\n\nThis has _nothing_ about any autoconf convention. GNU autoconf requires \nstupid things like having a bunch of files such as CREDITS, INSTALL, \nCHANGELOG, and other whatnots even if you have nothing to put in them, \nin which case they still have to be there but empty. It also dictates \nthe exact name your directories must have, etc.\n\nI'm not proposing a tree reorganization because GNU autoconf commands \nit, but rather because this is a sensible thing to do.\n\n> If there's a compelling reason to change, could someone please describe it?\n\nIt's about the third time I'm putting forward arguments for this. \nPlease see the list archive.\n\nP.S. the netiquette on busy mailing lists recommends that you preserve \nall the email addresses that were listed as recipients on the message \nyou reply to. That would be highly appreciated.\n\n\nNicolas\n"},{"id":"160319","messageId":"buo39o535gj.fsf@dhlpc061.dev.necel.com","threadId":"26384","inReplyTo":"alpine.LFD.2.00.1102030036420.12104@xanadu.home","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2011-02-03T08:09:00Z","receivedAt":"2011-02-03T08:09:00Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Nicolas Pitre writes:\n>> But just moving the whole existing pile into a subdirectory \"because\n>> everyone else does it\" is not a reason; that's superstition.\n>\n> There is no superstition here, simply basic elegance.\n\n\"basic elegance\" is hardly well-defined, and although there are probably\nissues on which there's general agreement, this doesn't appear to be one\nof them.\n\n>> Having to type \"src/\" a lot more often is definitely a downside.\n>\n> Come on. This is a rather egocentric argument without much substance.\n\nIt certainly has more substance than hand-waving like \"basic elegance\"\nthough...\n\nSome slightly more concrete arguments have been:\n\n Pro-src: Big top-level dir scares newbs\n Anti-src: Extra typing is annoying\n\nI'm not really against a \"src/\" subdir, but it seems mostly a matter of\ntaste, and I've seen plenty of projects where the src/ directory seemed\npretty pointless...\n\n-Miles\n\n-- \nPolitics, n. A strife of interests masquerading as a contest of\nprinciples. The conduct of public affairs for private advantage.\n"},{"id":"160341","messageId":"m2fws5m1z5.fsf@igel.home","threadId":"26384","inReplyTo":"alpine.LFD.2.00.1102030036420.12104@xanadu.home","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2011-02-03T18:01:34Z","receivedAt":"2011-02-03T18:01:34Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Nicolas Pitre writes:\n\n> This has _nothing_ about any autoconf convention. GNU autoconf requires \n> stupid things like having a bunch of files such as CREDITS, INSTALL, \n> CHANGELOG, and other whatnots even if you have nothing to put in them, \n> in which case they still have to be there but empty. It also dictates \n> the exact name your directories must have, etc.\n\nThat's automake, not autoconf (and only the default automake operation).\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"160343","messageId":"AANLkTimnMDuAX-Ctc5K3mt=b2bz2FTsb_P7Fs8RzVwpd@mail.gmail.com","threadId":"26384","inReplyTo":"alpine.LFD.2.00.1102030036420.12104@xanadu.home","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2011-02-03T18:46:03Z","receivedAt":"2011-02-03T18:46:03Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"On Thu, Feb 3, 2011 at 1:16 AM, Nicolas Pitre wrote:\n> On Tue, 1 Feb 2011, George Spelvin wrote:\n>\n>> For what it's worth, I don't see the \"cleanup\".\n>>\n>> If it significantly reduced the size of the largest directory,\n>> that would be a win.  But moving everything into src/ doesn't\n>> do that.\n>>\n>> If there's a way to divide the source into cohesive subunits, that\n>> would be great.  A programmer could ignore whole subdirectories\n>> when working on something.\n>>\n>> But just moving the whole existing pile into a subdirectory \"because\n>> everyone else does it\" is not a reason; that's superstition.\n>\n> There is no superstition here, simply basic elegance.\n>\n> When you pick up a book from a shelf, do you see the actual content of\n> the book printed right from the inside of the cover page, and the table\n> of content tossed in the margin?  Would you construct a book yourself\n> that way?\n>\n> A nice source tree should be organized with a minimum of hierarchical\n> structure.  To a newbie wanting to contribute to Git, it is rather\n> frightening to cd into the git directory and see that ls generates more\n> than 280 entries.  That simply looks sloppy.  And this gets much worse\n> after a make.\n>\n> The top directory should make different things stand out much more\n> clearly, like a preface and a table of content.  You have the\n> documentation here, the source there, the tests there, a clearly visible\n> README file, etc.  If the src directory has about the same relative\n> number of files after a move that's fine.  At least you should expect\n> _only_ source files in there (and possibly their by-products), and not\n> other types of data buried into the mix.\n>\n>> Having to type \"src/\" a lot more often is definitely a downside.\n>\n> Come on.  This is a rather egocentric argument without much substance.\n>\n>> Heck, that's one thing I actively dislike about GNU autoconf conventions.\n>\n> This has _nothing_ about any autoconf convention.  GNU autoconf requires\n> stupid things like having a bunch of files such as CREDITS, INSTALL,\n> CHANGELOG, and other whatnots even if you have nothing to put in them,\n> in which case they still have to be there but empty.  It also dictates\n> the exact name your directories must have, etc.\n>\n> I'm not proposing a tree reorganization because GNU autoconf commands\n> it, but rather because this is a sensible thing to do.\n>\n>> If there's a compelling reason to change, could someone please describe it?\n>\n> It's about the third time I'm putting forward arguments for this.\n> Please see the list archive.\n>\n> P.S. the netiquette on busy mailing lists recommends that you preserve\n> all the email addresses that were listed as recipients on the message\n> you reply to.  That would be highly appreciated.\n>\n>\n> Nicolas\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n\nI'm not a hacker, but a user who had sometimes peeked into the git\nsources. Unbelievable mess... Impossible to see the structure in\ncommand line interface.\nI totally agree with Nicolas here.\nFolders were invented for a reason.\n\nIMHO\nsrc for source code\nbuild for build by-products\ntests for tests\n\nCome on, give us some love, please!;)\n\nThanks,\nEugene\n"},{"id":"160357","messageId":"AANLkTikhPRGZ9DxCWbWvBiac_DYiXYsnEdHVOnbHUdU4@mail.gmail.com","threadId":"26384","inReplyTo":"AANLkTimnMDuAX-Ctc5K3mt=b2bz2FTsb_P7Fs8RzVwpd@mail.gmail.com","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2011-02-03T21:42:27Z","receivedAt":"2011-02-03T21:42:27Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 3 February 2011 10:46, Eugene Sajine wrote:\n> On Thu, Feb 3, 2011 at 1:16 AM, Nicolas Pitre wrote:\n>> On Tue, 1 Feb 2011, George Spelvin wrote:\n>>\n>>> For what it's worth, I don't see the \"cleanup\".\n>>>\n>>> If it significantly reduced the size of the largest directory,\n>>> that would be a win.  But moving everything into src/ doesn't\n>>> do that.\n>>>\n>>> If there's a way to divide the source into cohesive subunits, that\n>>> would be great.  A programmer could ignore whole subdirectories\n>>> when working on something.\n>>>\n>>> But just moving the whole existing pile into a subdirectory \"because\n>>> everyone else does it\" is not a reason; that's superstition.\n>>\n>> There is no superstition here, simply basic elegance.\n>>\n>> When you pick up a book from a shelf, do you see the actual content of\n>> the book printed right from the inside of the cover page, and the table\n>> of content tossed in the margin?  Would you construct a book yourself\n>> that way?\n>>\n>> A nice source tree should be organized with a minimum of hierarchical\n>> structure.  To a newbie wanting to contribute to Git, it is rather\n>> frightening to cd into the git directory and see that ls generates more\n>> than 280 entries.  That simply looks sloppy.  And this gets much worse\n>> after a make.\n>>\n>> The top directory should make different things stand out much more\n>> clearly, like a preface and a table of content.  You have the\n>> documentation here, the source there, the tests there, a clearly visible\n>> README file, etc.  If the src directory has about the same relative\n>> number of files after a move that's fine.  At least you should expect\n>> _only_ source files in there (and possibly their by-products), and not\n>> other types of data buried into the mix.\n>>\n>>> Having to type \"src/\" a lot more often is definitely a downside.\n>>\n>> Come on.  This is a rather egocentric argument without much substance.\n>>\n>>> Heck, that's one thing I actively dislike about GNU autoconf conventions.\n>>\n>> This has _nothing_ about any autoconf convention.  GNU autoconf requires\n>> stupid things like having a bunch of files such as CREDITS, INSTALL,\n>> CHANGELOG, and other whatnots even if you have nothing to put in them,\n>> in which case they still have to be there but empty.  It also dictates\n>> the exact name your directories must have, etc.\n>>\n>> I'm not proposing a tree reorganization because GNU autoconf commands\n>> it, but rather because this is a sensible thing to do.\n>>\n>>> If there's a compelling reason to change, could someone please describe it?\n>>\n>> It's about the third time I'm putting forward arguments for this.\n>> Please see the list archive.\n>>\n>> P.S. the netiquette on busy mailing lists recommends that you preserve\n>> all the email addresses that were listed as recipients on the message\n>> you reply to.  That would be highly appreciated.\n>>\n>>\n>> Nicolas\n>> --\n>> To unsubscribe from this list: send the line \"unsubscribe git\" in\n>> the body of a message to majordomo@vger.kernel.org\n>> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>>\n>\n> I'm not a hacker, but a user who had sometimes peeked into the git\n> sources. Unbelievable mess... Impossible to see the structure in\n> command line interface.\n> I totally agree with Nicolas here.\n> Folders were invented for a reason.\n>\n> IMHO\n> src for source code\n> build for build by-products\n> tests for tests\n>\n> Come on, give us some love, please!;)\n\nAnother one from the peanut gallery. :-) I wholeheartedly agree with\nboth Nicolas and Eugene.\n\nQuite frankly, I'm surprised there are (presumably experienced)\ndevelopers who do not immediately see the value of a little\norganization. Surely, given the use of code conventions, formatting\nrules, etcetera, the obvious one step further is to also organize\nwhere the files go?\n\n(Given that I'm just a lurker I promise to leave it at this. I just\nwanted to show Nicolas a little support.)\n"},{"id":"160373","messageId":"87bp2sy2mf.fsf@catnip.gol.com","threadId":"26384","inReplyTo":"AANLkTikhPRGZ9DxCWbWvBiac_DYiXYsnEdHVOnbHUdU4@mail.gmail.com","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2011-02-04T02:06:48Z","receivedAt":"2011-02-04T02:06:48Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Hilco Wijbenga writes:\n> Quite frankly, I'm surprised there are (presumably experienced)\n> developers who do not immediately see the value of a little\n> organization. Surely, given the use of code conventions, formatting\n> rules, etcetera, the obvious one step further is to also organize\n> where the files go?\n\nI think one of the problems is that what's been suggested seems like\nwindow-dressing. Moving everything into src/ and calling it \"organized\"\ndoesn't actually accomplish much other than perhaps making the README\nfile more visible to newbs; things are _still_ a mess, just a mess with\nfour more letters...\n\n-Miles\n\n-- \nBack, n. That part of your friend which it is your privilege to contemplate in\nyour adversity.\n"},{"id":"160379","messageId":"AANLkTinQ13b9c1=SmMSC5ThjXcsSuMO2irwW04E+K=xY@mail.gmail.com","threadId":"26384","inReplyTo":"87bp2sy2mf.fsf@catnip.gol.com","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Tor Arntsen","fromEmail":"tor@spacetec.no","sentAt":"2011-02-04T08:30:10Z","receivedAt":"2011-02-04T08:30:10Z","isPatch":false,"sender":{"key":"tor@spacetec.no","avatar":null},"body":"On Fri, Feb 4, 2011 at 03:06, Miles Bader wrote:\n> Hilco Wijbenga writes:\n>> Quite frankly, I'm surprised there are (presumably experienced)\n>> developers who do not immediately see the value of a little\n>> organization. Surely, given the use of code conventions, formatting\n>> rules, etcetera, the obvious one step further is to also organize\n>> where the files go?\n>\n> I think one of the problems is that what's been suggested seems like\n> window-dressing.  Moving everything into src/ and calling it \"organized\"\n> doesn't actually accomplish much other than perhaps making the README\n> file more visible to newbs; things are _still_ a mess, just a mess with\n> four more letters...\n\nWhat Miles says is my feeling as well. And having a 'bin/' as was suggested\nin one post doesn't make much sense to me either - if you want your compiled\noutput to go elsewhere than the source directory then the normal way of doing\nthat is to do and out-of-tree build (so if that's not working - I have\nnot checked -\nthen that's something which would be worth looking into.)\n\n-Tor\n"},{"id":"160389","messageId":"m3r5bo848w.fsf@localhost.localdomain","threadId":"26384","inReplyTo":"AANLkTinQ13b9c1=SmMSC5ThjXcsSuMO2irwW04E+K=xY@mail.gmail.com","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-02-04T10:49:32Z","receivedAt":"2011-02-04T10:49:32Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Tor Arntsen writes:\n> On Fri, Feb 4, 2011 at 03:06, Miles Bader wrote:\n> > Hilco Wijbenga writes:\n>>>\n>>> Quite frankly, I'm surprised there are (presumably experienced)\n>>> developers who do not immediately see the value of a little\n>>> organization. Surely, given the use of code conventions, formatting\n>>> rules, etcetera, the obvious one step further is to also organize\n>>> where the files go?\n>>\n>> I think one of the problems is that what's been suggested seems like\n>> window-dressing.  Moving everything into src/ and calling it \"organized\"\n>> doesn't actually accomplish much other than perhaps making the README\n>> file more visible to newbs; things are _still_ a mess, just a mess with\n>> four more letters...\n> \n> What Miles says is my feeling as well. And having a 'bin/' as was suggested\n> in one post doesn't make much sense to me either - if you want your compiled\n> output to go elsewhere than the source directory then the normal way of doing\n> that is to do and out-of-tree build (so if that's not working - I have\n> not checked - then that's something which would be worth looking into.)\n\nIt is about supporting 'srcdir', isn't it?\n\nBTW. what about using 'lib/' directory?\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"160390","messageId":"AANLkTinFHs=sgcPSAdPMrCORpzTO7no-6CqUi_9AFzXQ@mail.gmail.com","threadId":"26384","inReplyTo":"87bp2sy2mf.fsf@catnip.gol.com","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2011-02-04T11:17:50Z","receivedAt":"2011-02-04T11:17:50Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Fri, Feb 4, 2011 at 3:06 AM, Miles Bader wrote:\n> Hilco Wijbenga writes:\n>> Quite frankly, I'm surprised there are (presumably experienced)\n>> developers who do not immediately see the value of a little\n>> organization. Surely, given the use of code conventions, formatting\n>> rules, etcetera, the obvious one step further is to also organize\n>> where the files go?\n>\n> I think one of the problems is that what's been suggested seems like\n> window-dressing.  Moving everything into src/ and calling it \"organized\"\n> doesn't actually accomplish much other than perhaps making the README\n> file more visible to newbs; things are _still_ a mess, just a mess with\n> four more letters...\n\nFWIW, I don't quite see what's wrong with \"window dressing\" here.\nMaking those files more visible is a good thing, IMO.\n\nBut I'm not so sure I agree that the rest of the source tree is such a\nmess that everyone makes it out to be. OK, there's a lot of\nsource-files on the top-level (which would be the src-level with this\nchange), but why is that such a bad thing? And if this is a big deal,\nperhaps moving libgit-sources to a separate folder would help?\n"},{"id":"160403","messageId":"20110204181550.GA14173@vidovic","threadId":"26384","inReplyTo":"87bp2sy2mf.fsf@catnip.gol.com","subject":"[1.8.0] Re: reorganize the mess that the source tree has become","fromName":"Nicolas Sebrecht","fromEmail":"nicolas.s.dev@gmx.fr","sentAt":"2011-02-04T18:15:50Z","receivedAt":"2011-02-04T18:15:50Z","isPatch":false,"sender":{"key":"nicolas.s.dev@gmx.fr","avatar":null},"body":"The 04/02/11, Miles Bader wrote:\n> Hilco Wijbenga writes:\n> > Quite frankly, I'm surprised there are (presumably experienced)\n> > developers who do not immediately see the value of a little\n> > organization. Surely, given the use of code conventions, formatting\n> > rules, etcetera, the obvious one step further is to also organize\n> > where the files go?\n> \n> I think one of the problems is that what's been suggested seems like\n> window-dressing. Moving everything into src/ and calling it \"organized\"\n> doesn't actually accomplish much other than perhaps making the README\n> file more visible to newbs; things are _still_ a mess, just a mess with\n> four more letters...\n\nSo it would be an ordered mess, at least. The current amount of files in\nthe root directory do make things harder for people not already familiar\nwith the content. FMHO, moving the source files into a subdirectory\ncould be only a first step to the good direction.\n\n-- \nNicolas Sebrecht\n"},{"id":"160413","messageId":"1296859660.1255.49.camel@drew-northup.unet.maine.edu","threadId":"26384","inReplyTo":"20110204181550.GA14173@vidovic","subject":"Re: [1.8.0] Re: reorganize the mess that the source tree has become","fromName":"Drew Northup","fromEmail":"drew.northup@maine.edu","sentAt":"2011-02-04T22:47:40Z","receivedAt":"2011-02-04T22:47:40Z","isPatch":false,"sender":{"key":"drew.northup@maine.edu","avatar":"https://avatars.githubusercontent.com/u/18331571?v=4"},"body":"\nOn Fri, 2011-02-04 at 19:15 +0100, Nicolas Sebrecht wrote:\n> The 04/02/11, Miles Bader wrote:\n> > Hilco Wijbenga writes:\n> > > Quite frankly, I'm surprised there are (presumably experienced)\n> > > developers who do not immediately see the value of a little\n> > > organization. Surely, given the use of code conventions, formatting\n> > > rules, etcetera, the obvious one step further is to also organize\n> > > where the files go?\n> > \n> > I think one of the problems is that what's been suggested seems like\n> > window-dressing. Moving everything into src/ and calling it \"organized\"\n> > doesn't actually accomplish much other than perhaps making the README\n> > file more visible to newbs; things are _still_ a mess, just a mess with\n> > four more letters...\n> \n> So it would be an ordered mess, at least. The current amount of files in\n> the root directory do make things harder for people not already familiar\n> with the content. FMHO, moving the source files into a subdirectory\n> could be only a first step to the good direction.\n\nNicolas,\nHaving once upon a time (in CVS days) taken over a project that was\nneatly organized into tons of folders I can say that more folders is not\nalways better.\nIf you are organizing things into modules by folders, and those things\nare mutually exclusive pre-compilation then doing so may make sense. If\nthe folders ADD value to the project by adding organization--as opposed\nto hiding disorganization--then they may have value.\n>From my meager hacking thus far (working on making utf-16 a more\nuser-friendly experience out-of-the-box) I have found that none of this\nis true (thus far) with the git codebase. In fact the one thing that\nwould have been useful is more in-code--and/or separate\nAPI-ish--documentation (it took me waaaay too long to figure out how git\nadd, aka git-add, works), but I am too much of a realist to expect that\nto change much. I most certainly DO NOT recommend that a mess of patches\nbe submitted to Junio to fix it (document what you are working on as you\nsee fit; I work on too many things to not document fairly extensively).\nI approach codebase reorganization the same way. I have seen the\ndestructive things it can do to a project when it becomes an end unto\nitself separate from the primary focus. In fact, what killed that first\nproject I mentioned was an argument about something that was not part of\nthe primary purpose of the project which exploded with a fury resembling\na religious confrontation. I do not want to see that happen to Git. I\ndidn't want to see that project die either, but when you exasperate\nenough of the core developers that's what happens. \n\n(My first job as project leader was to get it off of our CVS host, the\nsecond was to find it a nice grave over at nongnu.org. I never did get\nCVS import to work. I never did convince any of the core developers that\nit was still worth working on.)\n\n-- \n-Drew Northup\n________________________________________________\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"160445","messageId":"20110205151143.GA14187@vidovic","threadId":"26384","inReplyTo":"1296859660.1255.49.camel@drew-northup.unet.maine.edu","subject":"[1.8.0] Re: reorganize the mess that the source tree has become","fromName":"Nicolas Sebrecht","fromEmail":"nicolas.s.dev@gmx.fr","sentAt":"2011-02-05T15:11:43Z","receivedAt":"2011-02-05T15:11:43Z","isPatch":false,"sender":{"key":"nicolas.s.dev@gmx.fr","avatar":null},"body":"The 04/02/11, Drew Northup wrote:\n\n> Having once upon a time (in CVS days) taken over a project that was\n> neatly organized into tons of folders I can say that more folders is not\n> always better.\n> If you are organizing things into modules by folders, and those things\n> are mutually exclusive pre-compilation then doing so may make sense. If\n> the folders ADD value to the project by adding organization--as opposed\n> to hiding disorganization--then they may have value.\n\nThis _is_ what we are talking about. Not tons of folders or whathever\nyou might think.\n\n> destructive things\n> killed that first\n> project\n> project exploded with a fury resembling\n> a religious confrontation. see that happen to Git\n> see that project die you exasperate\n> enough of the core developers\n\nRead again. I'm pretty sure this was not your goal but this almostly\nlooks like FUD to me. So, I don't think I'll involve to more discussion\nin this subthread.\n\n-- \nNicolas Sebrecht\n"}]}