Re: [RFC/PATCH 0/3] Thinning the git toplevel directory

[Jeff King <peff@peff.net>]

On Fri, Feb 18, 2011 at 03:25:18AM -0600, Jonathan Nieder wrote:

> Thanks again for both of your help.  I've put up an updated series at
> 
>  git://repo.or.cz/git/jrn.git flatten-source

s/flatten/un&/

> Changes since the series sent to the list:
> 
>  - put headers in libgit/ with the source files.  I don't
>    know what I was thinking before.

That is much nicer, I think.

>  - renamed nonbuiltin/ to commands/.  Names like
>    commands/add--interactive.perl even seem to make a kind of sense.

Definitely a better name.

>  - moved the http support mini-library to http/.

Seems like a weird one-off to me, as it only has two files.

>  - renamed git_remote_helpers to python/, though I'm not very happy
>    about that.

I think this has been discussed a couple of times, and there was some
confusion about what the directory means. It is "this is a python
library called git_remote_helpers". It is not "this is generic python
code for git", nor is it "this is generic remote helper code". So I
think python/git_remote_helpers would probably be a more appropriate
name in case we ever grow more python code.

> This is all very off-the-cuff.  I'd be happy for others to pick this
> up and remold it to their taste (after all, I'm too used to the
> current layout to remember what matters).  It doesn't feel cooked yet.

Two overall comments that are vague and you can feel free to ignore:

  1. I was one of the initial complainers of a source reorganization.
     But my complaint was mainly "let's only do it if there is some real
     benefit". Unlike simply shoving everything most of what's in the
     top-level into a src/ directory, I think this is shaping up to be a
     real reorganization, and the structure is easier to look at.

  2. I found it most instructive to actually checkout the result and
     look at the organization from a new user perspective. Here are my
     impressions:

       - There are a still a lot of directories. I wonder if we should
         be going deeper. Like commands/builtin. Or lib/*.

       - Some names seem funny. Like "gitk-git", which really should
         just be "gitk". But I think that is a limitation of the subtree
         merge. Maybe it's time for us to eat our own submodules
         dogfood? :)

       - Before build, "ls | wc -l" reports 35 entries. Afterwards, it
         reports 213, and any structure you uncovered in reorganization
         is lost. Maybe that doesn't matter, since the clean tree is
         what people will see first when they are getting their
         bearings. Or maybe not, since maybe they build first, then
         hack. I dunno. I'm not sure what the solution is. There are
         some obvious things, like throwing the test-* built executables
         into test-programs (which will require some magic in
         test-lib.sh to find them). Maybe git-* should stay in commands.
         I dunno.

-Peff