On Fri, Feb 18, 2011 at 03:25:18AM -0600, Jonathan Nieder wrote:
> Thanks again for both of your help. I've put up an updated series at
>
> git://repo.or.cz/git/jrn.git flatten-source
s/flatten/un&/
> Changes since the series sent to the list:
>
> - put headers in libgit/ with the source files. I don't
> know what I was thinking before.
That is much nicer, I think.
> - renamed nonbuiltin/ to commands/. Names like
> commands/add--interactive.perl even seem to make a kind of sense.
Definitely a better name.
> - moved the http support mini-library to http/.
Seems like a weird one-off to me, as it only has two files.
> - renamed git_remote_helpers to python/, though I'm not very happy
> about that.
I think this has been discussed a couple of times, and there was some
confusion about what the directory means. It is "this is a python
library called git_remote_helpers". It is not "this is generic python
code for git", nor is it "this is generic remote helper code". So I
think python/git_remote_helpers would probably be a more appropriate
name in case we ever grow more python code.
> This is all very off-the-cuff. I'd be happy for others to pick this
> up and remold it to their taste (after all, I'm too used to the
> current layout to remember what matters). It doesn't feel cooked yet.
Two overall comments that are vague and you can feel free to ignore:
1. I was one of the initial complainers of a source reorganization.
But my complaint was mainly "let's only do it if there is some real
benefit". Unlike simply shoving everything most of what's in the
top-level into a src/ directory, I think this is shaping up to be a
real reorganization, and the structure is easier to look at.
2. I found it most instructive to actually checkout the result and
look at the organization from a new user perspective. Here are my
impressions:
- There are a still a lot of directories. I wonder if we should
be going deeper. Like commands/builtin. Or lib/*.
- Some names seem funny. Like "gitk-git", which really should
just be "gitk". But I think that is a limitation of the subtree
merge. Maybe it's time for us to eat our own submodules
dogfood? :)
- Before build, "ls | wc -l" reports 35 entries. Afterwards, it
reports 213, and any structure you uncovered in reorganization
is lost. Maybe that doesn't matter, since the clean tree is
what people will see first when they are getting their
bearings. Or maybe not, since maybe they build first, then
hack. I dunno. I'm not sure what the solution is. There are
some obvious things, like throwing the test-* built executables
into test-programs (which will require some magic in
test-lib.sh to find them). Maybe git-* should stay in commands.
I dunno.
-Peff
--
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