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
> 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
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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html