kiranpyati <kiran.pyati@xxxxxxxxxxxxx> writes: > We want a way to seamlessly sync production and Git. You should be aware that Git was not designed for this scenario. The usual flow with Git (and actually with most revision control systems), is to do the development with Git, then use your build system to generate a package that can be used in production (e.g. generate a .tar.gz, or a .jar, or whatever your platform needs), and then install this package on your production server. It can be tempting, however, to use your revision control system as a deployment tool, so that an update on the production server be as simple as "git pull". But in real-life applications, it usually has to be more complicated: do you need to generate some files after you fetch the latest version of the source? Do you need to update your database? Isn't the .git/ directory harmfull here (e.g. do I want the full history source of my project to be visible worldwide if this is a webapplication?) ... If you insist in using Git for deployment, then you should absolutely stick to it. Whether for deployment or for anything else, trying to send changes using both Git and other mechanism (e.g. uploading files directly to a working tree as you did) puts you in trouble 99.9% of the cases. In your case, the damage is already done. If I were you, I'd do something like <do some backup> <make sure the backup is OK> <think twice "will I be able to restore the backup if it goes wrong?"> $ git fetch origin $ git reset --hard origin/master (actually, if I were you, I'd try reproducing the situation on a non-production server first) "git fetch" will download the revisions from the remote server, which should be the repository where the version you want to run is located. "git reset --hard" will discard any local change (committed or not) you may have, and set your local working tree to the latest version in the master branch of the remote repository. You may need a "git clean" to remove untracked files too. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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