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

From: Andreas Ericsson <ae@op5.se>
Date: Jan 18, 2008, 08:41 UTC
Message-ID: <47906643.2010201@op5.se>
In-Reply-To: <478EEAC4.2010006@talkingspider.com>

Mike wrote:

Show 20 quoted lines

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

We develop several different PHP packages. We have a test-server where pandemonium reings with regards to .git directories and which branches are checked out where. We also have a release process, and .git dirs *never* end up on production servers.

The release-process is this: "git tag -s $tag_name; git push $tag_name". The update-hook then marks the repo as having a new release and a cron- job, running every 5 minutes, takes care of updating our production servers. It took me all of 30 minutes to hack up, and not only does it make sure we never publish the .git directory, it also makes it really, really easy for <insert-non-git-savvy-customer-X> to report a version in which he or she has spotted a bug.

Show 6 quoted lines

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

You accomplish that by making sure only stable and signed versions hit the deployment server(s). Manual scp/rsync/ftp-mirroring of the testing server's docroot is just plain stupid.

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

Well, it was originally intended to manage the Linux kernel, but it's written in such a way as to be capable of competently manage just about anything.

Show 15 quoted lines

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

Those problems aren't "all the scm's in the world store their meta-data somewhere!" though, and the ability to tar up a working-tree and get the git-directory too is not always a bad thing. It's just your release process that needs to eliminate the manual step there so you never copy it by accident. That's why people write small and simple scripts though.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231