Junio C Hamano wrote: > Jonathan Nieder <jrnieder@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html