On Jan 17, 2008 6:42 PM, Mike <fromlists@talkingspider.com> wrote:
quoted text
> With PHP, Python, and Ruby, the development is the deployment.  The

Plenty here use git for web apps.

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.

*First* - people here have pointed out various ways of doing this with
the GIT_DIR env variable. Nothing is being violated.

In terms of the best-practice you mention of publishing only the
reachable files, your checkout is one directory higher. The top-level
dir of your checkout should look like:

  .git
  htdocs # this is published
  conf # configuration files
  lib # libraries

if you publish the top of your checkout, your libraries sit in there.
Along your .git and your config files.

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

Well -- I routinely add .git CVS and .svn to http.conf with a
directorymatch clause to prevent access to them. Just in case,
belts-and-suspenders.

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

Nah! It'll be because of a long list of things, including temp files,
backup files that developers make, all sorts of things in your *work*
dir that you really need there and you really should _not_ have in the
production checkout.

BTW, I also add common patterns for those temp files to httpd.conf to
restrict access to them.

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?

C produces a ton of intermediary files that git never commits, and C
projects usually get an "installer" too (debian's apt/dpkg, rpm, etc).
Writing PHP/Ruby/Python produces less "intermediary" files, but it
still creates some, so there's plenty of good reasons to have an
"installer".

GIT does the SCM thing, but for handling your deployment you need
something else. I normally use scripts that use git internally,
written in make, perl or shell.

cheers,



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