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

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Feb 19, 2011, 11:11 UTC
Message-ID: <20110219111103.GA1841@elie>
In-Reply-To: <7vei75p3zr.fsf@alter.siamese.dyndns.org>

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?

Show 6 quoted lines

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