On Wed, 16 Jan 2008, Mike wrote: > > Neil Macneale wrote: > > > > It seems to me that you are asking git to be your deployment software, > > which is a bad fit. > > I'm asking git to get out of my deployment! I think you mis-understood. The normal way of handling this is to NOT DO DEVELOPMENT IN YOUR DEPLOYMENT TREE! 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) So while you can do various tricks (symlinking ".git", using GIT_DIR, etc etc) to get the .git contents out of your worktree, the thing is, the correct thing to do is almost always to simply re-think the whole problem, and come at it the other way: rather than getting .git out of your development tree, you should consider getting your development tree out of your deployment area! Let me do a few examples of why this is a good idea: - the whole point of development trees and SCM's (and that's *especially* true with git) is how you can try things out, go backwards in time, and generally just do *development*. If you do that in what is your public deployment area, you're already very limited. Not only may you not want to make that .git directory accessible to others (while you *do* obviously want to make the deployment itself), you also end up exposing things like your management scripts and source code along with "generated files" etc that are the things you actually want to deploy. Yes, it's certainly quite possible that you simply don't have any management scripts etc, and that you don't generate any files, and you simply want to just deploy the exact files that you also want to track. But that really is a fairly unusual thing to do. - with git in particular, you lose a lot of the capabilities if you are forcing yourself to have "deployment == development tree". Things like switching branches for managing different versions suddenly are painful, because you're artificially forcing a 1:1 relationship between "development" and "deployment". - Most sane people want to deploy and test separately. In particular, you want to test *before* you deploy. People make mistakes, they don't want to show them. Or there are consistency requirements, and/or you simply want to deploy to multiple sites simultaneously. All of which really re-inforces the "develop separately" mentality, where the actual deployment is then a separate "now I'm ready, let's push out the result". Now, maybe none of these things are issues at all for you. Good for you. But hopefully this explains why most people don't have your issues, and why people try to tell you that "deployment software" is a separate thing from "source control management", and you often want both, and _want_ to keep them separate. Linus - 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
