Mike wrote:
quoted text
> 
> 
> 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.

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

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


quoted text
> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html