Jonathan Nieder [off-list ref] writes:

Thanks again for both of your help.  I've put up an updated series at

 git://repo.or.cz/git/jrn.git flatten-source

Huh?  Did you mean deepen or unflatten?

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.

Nicer; I liked Jeff's "lib/" even better, though.

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

Yes. "nonbuiltin/" made me stop reading the patches ;-).

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

I don't understand the motivation behind this---wouldn't it belong to
"libgit/" and if not why not?

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

I am not fond of naming a directory after a language _unless_ the contents
of the directory is _all_ about laying the foundation of something else
that happens to be implemented in that language.  Existing "perl/" is all
about providing the Git.pm module to be used by Perl scripts that live
outside the directory and is a very good example of naming the directory
after the language.  Does the contents of the new "python/" directory
satisfy that criteria?  If so, then it is fine.  If we plan to add more
remote-helpers and if we plan to allow these helpers written in other
languages, you might need to resurrect a separate "remote-helpers/"
directory, move some parts of the files you placed in "python/" that are
not "foundations for talking to git from Python" but are about "being a
remote-helper" to a subdirectory of it, so that new helper implementations
written in other languages can live next to that subdirectory.

For exactly the same reason "scripts/" is a name I am not entirely happy
about in your tree.  "test-programs/" is a very good name, but "scripts/"
only tells us that the contents _happen to be_ done as scripts, and does
not tell us _what they are for_; perhaps "build-helpers/" might be more
understandable.

Thanks.