On Fri, 2011-02-04 at 19:15 +0100, Nicolas Sebrecht wrote: > The 04/02/11, Miles Bader wrote: > > Hilco Wijbenga <hilco.wijbenga@xxxxxxxxx> writes: > > > 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? > > > > I think one of the problems is that what's been suggested seems like > > window-dressing. Moving everything into src/ and calling it "organized" > > doesn't actually accomplish much other than perhaps making the README > > file more visible to newbs; things are _still_ a mess, just a mess with > > four more letters... > > So it would be an ordered mess, at least. The current amount of files in > the root directory do make things harder for people not already familiar > with the content. FMHO, moving the source files into a subdirectory > could be only a first step to the good direction. Nicolas, Having once upon a time (in CVS days) taken over a project that was neatly organized into tons of folders I can say that more folders is not always better. If you are organizing things into modules by folders, and those things are mutually exclusive pre-compilation then doing so may make sense. If the folders ADD value to the project by adding organization--as opposed to hiding disorganization--then they may have value. >From my meager hacking thus far (working on making utf-16 a more user-friendly experience out-of-the-box) I have found that none of this is true (thus far) with the git codebase. In fact the one thing that would have been useful is more in-code--and/or separate API-ish--documentation (it took me waaaay too long to figure out how git add, aka git-add, works), but I am too much of a realist to expect that to change much. I most certainly DO NOT recommend that a mess of patches be submitted to Junio to fix it (document what you are working on as you see fit; I work on too many things to not document fairly extensively). I approach codebase reorganization the same way. I have seen the destructive things it can do to a project when it becomes an end unto itself separate from the primary focus. In fact, what killed that first project I mentioned was an argument about something that was not part of the primary purpose of the project which exploded with a fury resembling a religious confrontation. I do not want to see that happen to Git. I didn't want to see that project die either, but when you exasperate enough of the core developers that's what happens. (My first job as project leader was to get it off of our CVS host, the second was to find it a nice grave over at nongnu.org. I never did get CVS import to work. I never did convince any of the core developers that it was still worth working on.) -- -Drew Northup ________________________________________________ "As opposed to vegetable or mineral error?" -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- 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