Re: [RFC] Code reorgnization

[Jeff King <peff@peff.net>]

On Thu, Mar 17, 2016 at 06:11:36PM +0700, Duy Nguyen wrote:

> Git's top directory is crowded and I think it's agreed that moving
> test-* to t/helper is a good move. I just wanted to check if we could
> take this opportunity (after v2.8.0) to move some other files too. I
> propose the following new subdirs

I guess I don't really see the "crowded" problem, but perhaps that is
because I am more or less familiar with where things are in git's code
base. I suppose if you were looking for a "utility" function, you might
look in "util" and therefore have a smaller set of files to check.

But I think we also run into the opposite problem: I am looking for some
particular function, but I can't find it, because I am looking in "util"
and it is in some other directory. And when files move around, it makes
history harder to follow (maybe that is because git sucks and we need to
make it better, but certainly I run into mild annoyances with the
builtin/ rename when digging in history).

And you have a similar problem when creating new files. Which slot do
they go in? What if they could feasibly go into two slots?

So there can be friction either way. In practice I find I just use ctags
to jump to the functions I am interested in, and I don't care that much
about filenames.

The reorganization that _would_ be more interesting to me is not files
in directories, but rather functions in files. I wish everything were
designed more as modules with a pair of matching ".c" and ".h" files,
with a public interface defined in the ".h", and messier, private stuff
in the ".c". But we have some real dumping grounds:

  1. cache.h has the declarations for at least a dozen different
     modules; besides being hard to navigate, it causes more frequent
     recompilation than necessary.

  2. a few of the .c files could probably be split (e.g., dir.c is where
     all of the pathspec code lives, even though that is used for much
     more than filesystem access these days).

Splitting those up would _also_ introduce friction (and actually worse
than whole-file renames, because finding code movement between files is
an even harder / more expensive problem). But I feel like it would buy a
lot more in terms of code clarity, and in reducing the scope of code
which has access to private, static interfaces.

-Peff