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

[Jonathan Nieder <jrnieder@gmail.com>]

Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:

>>  git://repo.or.cz/git/jrn.git flatten-source
>
> Huh?  Did you mean deepen or unflatten?

The branch name was unflatten-source.  Sorry about that.

I've pushed some more simple tweaks.

 - remove the ".sh" suffix from most build helpers
 - rename scripts/ to build-helpers/.  Much nicer.
 - rename libgit/ to lib/.  The shorter pathnames this allows are much
   nicer.
 - move compat/ under the lib/ umbrella
 - merge builtins/ with commands/.  It never was clear to me why
   making a command builtin should require changing its filename.
 - rename gitk-git/ to gitk/
 - rename t/ to tests/, to get a sense for what that feels like

Some remaining details:

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

They are not linked into the main git binary, to avoid a dependency on
libcurl and libexpat.  So it might (or might not) be useful to keep
them in a subdir to avoid tempting people to use those functions when
not appropriate.

lib/http/, with a README explaining their special status?

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

"git remote-testgit" uses it for
 - basic utility functions (die, debug, warn)
 - accessing a git repository and listing its branches (GitRepo)
 - running git fast-export (GitExporter) and keeping a marks file
   between runs
 - running git fast-import (GitImporter) and keeping a marks file
   between runs
 - maintaining a mirror of a non-local git repo (NonLocalGit) to
   be able to run fast-export from it

I am guessing a longer term plan is for it to acquire subpackages with
analagous functionality accessing other version control systems.  It
would be tempting to do

 other-vcs/
	bazaar/
	git/
	mercurial/
	subversion/

(intermixing C and Python code) but that doesn't work because it does
not match the structure of the git_remote_helpers package.

Side note: I am not sure I like the git_remote_helpers name.  Wouldn't
a good goal be for these modules to be usable by other VCSes'
import/export scripts, too?

Thanks for the comments.