Am 9/5/2013 23:43, schrieb Eyal Zinder: > I'm trying to setup a distributed development repository with a central > repository acting as the production copy. I'm doing so on a Windows > file share with no SSH / HTTP accessibility. Basically each developer > will have their own copy of the project, and the shared drive should > have a copy of the master copy (prod/master branch), along with the > work-tree files. > > The idea is that any developer should be able to do independent > development, staged commits, etc.. then push to the central (origin) > repository, and production scripts will reflect these changes upon a > push. > > I got pretty close to this setup by creating a bare repository on the > file share server (f:\GitDBs\foo.git), then cloning the bare repository > onto the production path like so: git clone f:\GitDBs\foo.git foo The setup sounds reasonable. > I cloned the bare repository just the same onto my local dev path.. and > proceeded with development. This worked fine, and I was able to push / > pull changes into "origin" (bare repo), and then I would go to my prod > (f:\foo) repository (clone of bare f:\GitDBs\foo.git), then pull the > changes.. So far my understanding is that your production directory only ever issues pulls from the bare repository. That is OK. > The problem I faced later on was in parallel development, when changes > were made to a file in one repository, and at the same time other > changes made to the same file in another repository.. I couldh't push > changes from the dev\foo to prod\foo or to origin.. Define "couldn't push". What are the error messages? Is it important that it is *the same file* to which changes were made at the same time? Do you have receive.denyNonFastForwards set in the bare repository? > I'm completely lost at the moment.. I try to set --git-dir or > --work-tree and I get mixed results.. Don't do that, it should not be necessary in your setup. -- Hannes -- 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