Re: [RFC/PATCH 0/3] Thinning the git toplevel directory
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:50:36
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.