From: Miles Bader <hidden> Date: 2016-06-15 22:50:30
Hilco Wijbenga [off-list ref] 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...
-Miles
--
Back, n. That part of your friend which it is your privilege to contemplate in
your adversity.
From: Tor Arntsen <hidden> Date: 2016-06-15 22:50:30
On Fri, Feb 4, 2011 at 03:06, Miles Bader [off-list ref] wrote:
Hilco Wijbenga [off-list ref] writes:
quoted
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...
What Miles says is my feeling as well. And having a 'bin/' as was suggested
in one post doesn't make much sense to me either - if you want your compiled
output to go elsewhere than the source directory then the normal way of doing
that is to do and out-of-tree build (so if that's not working - I have
not checked -
then that's something which would be worth looking into.)
-Tor
From: Jakub Narebski <hidden> Date: 2016-06-15 22:50:30
Tor Arntsen [off-list ref] writes:
On Fri, Feb 4, 2011 at 03:06, Miles Bader [off-list ref] wrote:
quoted
Hilco Wijbenga [off-list ref] writes:
quoted
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...
What Miles says is my feeling as well. And having a 'bin/' as was suggested
in one post doesn't make much sense to me either - if you want your compiled
output to go elsewhere than the source directory then the normal way of doing
that is to do and out-of-tree build (so if that's not working - I have
not checked - then that's something which would be worth looking into.)
It is about supporting 'srcdir', isn't it?
BTW. what about using 'lib/' directory?
--
Jakub Narebski
Poland
ShadeHawk on #git
From: Erik Faye-Lund <hidden> Date: 2016-06-15 22:50:30
On Fri, Feb 4, 2011 at 3:06 AM, Miles Bader [off-list ref] wrote:
Hilco Wijbenga [off-list ref] writes:
quoted
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...
FWIW, I don't quite see what's wrong with "window dressing" here.
Making those files more visible is a good thing, IMO.
But I'm not so sure I agree that the rest of the source tree is such a
mess that everyone makes it out to be. OK, there's a lot of
source-files on the top-level (which would be the src-level with this
change), but why is that such a bad thing? And if this is a big deal,
perhaps moving libgit-sources to a separate folder would help?
From: Nicolas Sebrecht <hidden> Date: 2016-06-15 22:50:30
The 04/02/11, Miles Bader wrote:
Hilco Wijbenga [off-list ref] writes:
quoted
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 Sebrecht
On Fri, 2011-02-04 at 19:15 +0100, Nicolas Sebrecht wrote:
The 04/02/11, Miles Bader wrote:
quoted
Hilco Wijbenga [off-list ref] writes:
quoted
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
From: Nicolas Sebrecht <hidden> Date: 2016-06-15 22:50:30
The 04/02/11, Drew Northup wrote:
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.
This _is_ what we are talking about. Not tons of folders or whathever
you might think.
destructive things
killed that first
project
project exploded with a fury resembling
a religious confrontation. see that happen to Git
see that project die you exasperate
enough of the core developers
Read again. I'm pretty sure this was not your goal but this almostly
looks like FUD to me. So, I don't think I'll involve to more discussion
in this subthread.
--
Nicolas Sebrecht