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

From: Andreas Ericsson <[email-masked]>
Date: Tue, 01 Feb 2011 15:42:12 +0100

On 01/31/2011 10:28 PM, Nicolas Pitre wrote:
> On Mon, 31 Jan 2011, Jeff King wrote:
> 
>> On Mon, Jan 31, 2011 at 03:28:37PM -0500, Nicolas Pitre wrote:
>>
>>> We do have subdirectories for documentation, tests, contributions, etc.
>>> But a sizeable part of the tree is just a big splat of source files
>>> dumped right in the root of the tree.
>>>
>>> So I'd suggest doing the following:
>>>
>>> 1) Create a src/ directory and move *.c, *.h, *.sh, *.perl, *.py and
>>>     the builtin directory from the root directory to it.
>>
>> Wouldn't this just be the same giant splat of source files, but in a
>> different tree? I don't really see the advantage, and it seems like an
>> extra annoyance.
> 
> Like I said to Junio, if you don't see the advantage, there's nothing I
> can do for you.  To me this is simple good source code hygiene.
> 
>> Besides being just one more directory to go up and down, it does make
>> history browsing more annoying. As much as I love git's "don't record
>> renames" philosophy, our handling of renames on the viewing side is
>> often annoying. I already get annoyed sometimes following stuff across
>> the s!builtin-!builtin/! change. This would be like that but more so.
> 
> So... we do suck at something?  So why not take this opportunity to
> shake yourself out of this easy comfort and improve Git as a result on
> both front?  :-)
> 
>> Or maybe it is a good thing for that reason, as we will eat our own
>> rename dogfood. :)
> 
> Exactly!  And maybe we'll make Git even more useful in the process.
> 
>>> 5) Rename t/ to testsuite/ so this doesn't look like some garbage
>>>     leftover.
>>
>> Ugh, more typing. :P
> 
> Come on!  You sound like an old fart now!  ;-)
> 

Personally, I kinda like the capital D in Documentation for tab
completion reasons. Keeping frequently used files and directories
with short unique prefixes makes perfect sense from a typing point
of view. Using longer mnemonic names makes perfect sense from a
regex search/replace point of view.

I'm kinda with Junio on the ./*.[ch] -> src/*.[ch] move though, but
perhaps that's just because I hate autoconf projects which generate
a ton of cruft in the root before one can even start building it.

It would probably help matters along if buildproducts ended up in
their own directory though. That way .gitignore won't have so many
extra commits when new source files are added, and 'make clean'
gets easier to maintain.

So to sum up what I'm for;

t/ -> Test/ (or Testsuite, but some more mnemonic name anyways
with a short unique prefix for tab completion). This would also
exercise our rename machinery quite a bit, altohugh not to the
point where people get annoyed if it gets sort-of-broken.

buildproducts to Build/ (capital B to avoid completing against
builtin*). This also has the benefit that %.o: %.c rules makes
tab completion work better when object files are already built,
and "git add git-foo.*" doesn't throw the "git-foo.o is ignored"
error and forces one to re-type it as "git-foo.[ch]"

The ppc stuff I don't really care about and it wouldn't be hard
to resurrect if we remove it and people complain. Everything
will also still work if we do, although with possibly a slight
decrease in performance.

Bulk of source-files stay as ./*.[ch]. I see absolutely no
benefit to moving them, but two potential drawbacks. One is that
it'll cause more typing for those of us who use console-based
editors and run 'make' manually (yes, we do exist). The afore-
mentioned merge+rebase hell is also a considerable drawback,
even though that's primarily an issue for maint releases.

Risks: Well... dunno about that really. Mucking up the build and
test systems, I suppose, but it's easy enough to test.

Cons: Rebasing and merging stuff to the Makefile and test-stuff
will suck a bit, but as has been pointed out that's not only a
bad thing.

Pros: Less typing all-round. Simpler "make clean" rules. Fewer
tacked-on .gitignore patches for new commands. We (well, Junio)
get to experience first-hand the problems of directory renames
across releases but on a smaller scale than moving *everything*
around in one go.

-- 
Andreas Ericsson                   [email-masked]
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.