Re: [RFC] Code reorgnization

[Duy Nguyen <pclouds@gmail.com>]

On Fri, Mar 18, 2016 at 12:24 PM, Jeff King <peff@peff.net> wrote:
> 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).

Yeah, for finding a particular function, I just "git grep" (or rgrep
from emacs) if I fail to locate it after the first guess. We have this
problem nowadays anyway. Besides builtin, we also have ewah, refs and
some more subdirs.

> 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?

Everything goes to topdir (or later on "src") by default and only goes
to "lib" when it's _obvious_ that it's disconnected from git (i'm
talking about the "lib/src" layout).

> 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).

Heh.. that's what I wanted to do (or at least discuss) after files are moved :)

> 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).

.. and this is why I did not raise it in the first mail.

> 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.
-- 
Duy