Hi, I always thought git allows concurrent access to a repository and expected that this also is true when working with local repositories. The only problem I was aware of is that the use of NFS and windows shares might cause problems. However I sometime see the following error messages in our concurrent build process.
message 1: Fetching origin error: cannot lock ref 'refs/remotes/origin/branchname Unable to create '/home/workingcopy/.git/refs/remotes/origin/ branchname.lock': File exists. If no other git process is currently running, this probably means a git process crashed in this repository earlier. Make sure no other git process is running and remove the file manually to continue. >From servername:gitrepo ! ccea072...349809e branchname -> origin/branchname (unable to update local ref) error: Could not fetch origin message 2: error: cannot lock ref 'refs/remotes/origin/master': ref refs/remotes/origin/master is at 07cd4a461229f9352d16063ff209e828cba592ea but expected 7c4ddcf998bad94f4f7e8e806baaa475f2069e60 message 3 (on git pull --rebase): Cannot rebase onto multiple branches Does that mean there is an issue inside git's locking or is concurrent access to the same workingcopy not supported at all? I expected the commands would blocking until they can acquire the lock, but It seems like there are other command which are either aborting or not locking at all (git pull -reabase). I think git pull --rebase is just a chain of other git commands where the lock is done on the individual steps. Am I doing something wrong or is it concurrent access just not support this way? Does that mean I have to use my own locks such as putting flock around each call? Best Regards Heiko Böttger -- 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
