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