Mike wrote:
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.
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.
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@xxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
