Re: I don't want the .git directory next to my code.

[Mike <fromlists@talkingspider.com>]

Linus Torvalds wrote:

> Some people don't split this up, and they tend to make horrible horrible 
> mistakes, like checking in the *results* of the post-processing too (ie 
> binary result blobs that can be regenerated from the other files), because 
> they don't make a clear separation between the parts they do development 
> on, and the end result.

Honestly, I think your mode of thinking is centered around compiled 
languages and linux app(/kernel) development.  The web app 
development/deployment model is very different.

With PHP, Python, and Ruby, the development is the deployment.  The 
source is the output.  You can't develop web apps in those languages 
unless the source files you're working on are under the doc root of your 
development server.   "the parts they do development on" and "the end 
result" *are* the same files.

The "development server -> staging server -> live
server" model has been around in common use for as long as web
applications have. In fact, the term "deployment" falls apart here. 
 From my web app developer perspective, the deployment is what lands on 
the live server.  For your git perspective, the "deployment" may mean 
the .../docroot/php directory for the development server (where our app 
code lives).

There's a fundamental "best practice" of web development being violated 
here- keep your docroots clean, only put stuff in them that should go 
live (or should eventually go live when ready).  Other files should not 
live under docroot.

Among the reasons for that is security.  If one of those .git dirs does 
slip out and go live, it's a *huge* *gaping* *security* *hole*.  You 
could download the repository because those files don't have extensions, 
so the browser would just download them. I could write a spider that 
crawls around the web appending /.git to urls.

If we end up having to write a special "publisher" app to move files 
from dev to live, then it will only be because of those damn .git 
directories.  More likely we'd add some exclusions into an rsync 
wrapper, I guess. And then still worry about tarring up the docroot (not 
all of which is gitted).  And then worry that some young developer on 
the team might SCP a directory's contents and he didn't notice that .git 
dir because it doesn't show up under "ls" or the "ll" alias.

Maybe git just isn't intended to be used for anything besides compiled
languages like c?  Or maybe just not for web app development?

Finally, to this statement:

> It's almost always a bad idea to develop in the tree that is also where
> you "export" things, and if you find git annoying in this respect, ask
> yourself why pretty much *every*single*scm*out*there* makes their
> infrastructure even more noticeable (eg CVS subdirectories in every 
single
> directory etc)

I don't think that pointing at other SCM's practices as the authority is 
the stance you really want to take. I can direct you to a video of a 
speech by a brilliant guy, in front of some googlers, where he explains 
that the entire reason he started the git project is because of the 
problems with "*every*single*scm*out*there*".

Mike