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

[Jonathan Nieder <jrnieder@gmail.com>]

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