Jeff King wrote: > On Fri, Feb 18, 2011 at 03:25:18AM -0600, Jonathan Nieder wrote: >> - moved the http support mini-library to http/. > > Seems like a weird one-off to me, as it only has two files. That was just to get the files out of the toplevel. I suspect the reason they are not part of libgit is to isolate the expat and curl linkage. Hmm, maybe an http/README explaining that would be nice. > So I > think python/git_remote_helpers would probably be a more appropriate > name in case we ever grow more python code. Good idea. So the layout would be: python/ Makefile git_remote_helpers/ ... > - There are a still a lot of directories. I wonder if we should > be going deeper. Like commands/builtin. Or lib/*. For reference: Documentation/ block-sha1/ fast, portable sha1 routine builtin/ built-in (busybox style) commands commands/ stand-alone commands compat/ compatibility replacements, platform-specific code contrib/ contributed software gitk-git/ gitk gitweb/ web interface git-gui/ gui http/ code for use in HTTP support commands (wraps curl and expat) libgit/ code for use in multiple commands perl/ Git.pm ppc/ fast sha1 routine in powerpc assembler python/ python-fastimport + a remote-helper protocol helper scripts/ build scripts t/ tests templates/ repository skeleton test-programs/ sample programs to exercise libgit, vcs-svn, and the sha1 lib xdiff/ diff generator vcs-svn/ svn interop To give an extreme example :), this could be pruned to Documentation/ commands/ contrib/ libgit/ scripts/ templates/ testsuite/ xdiff/ by - not distinguishing builtins from non-builtins by filename - dropping gitk, git gui, and gitweb from the tree - moving test programs into the testsuite - moving sha1 implementations and compatibility code under libgit - including http support files in libgit/ even though they are not part of libgit.a - moving perl and python libraries under libgit > - Some names seem funny. Like "gitk-git", which really should > just be "gitk". I think it was originally to make the transition from file to directory smoother. > But I think that is a limitation of the subtree > merge. Should work fine, no? Since / in common ancestor matches gitk/ in HEAD, that would be the detected shift. (Caveat: I haven't tried it.) > - Before build, "ls | wc -l" reports 35 entries. Afterwards, it > reports 213, and any structure you uncovered in reorganization > is lost. I think the best way to fix this is to provide support[1] for make O=build/ for those who want to maintain a clean source tree. Thanks for some good ideas. Jonathan [1] There's a skeleton of such support here: http://thread.gmane.org/gmane.comp.version-control.git/165720/focus=165850 I don't think I'm the right one to take it further, though, since I don't really like to use "make O=elsewhere". -- 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