{"thread":{"id":"41776","subject":"git and concurrent access to local repository","startedAt":"2016-03-22T08:00:13Z","lastAt":"2016-03-23T07:08:22Z","messageCount":3,"participants":["Boettger, Heiko","Torsten Bögershausen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"281416","messageId":"8C0042D8869AEA4AA334B49AFBBCEF82B53CF505@TUT-EX02-PV.KSTG.corp","threadId":"41776","inReplyTo":null,"subject":"git and concurrent access to local repository","fromName":"Boettger, Heiko","fromEmail":"heiko.boettger@karlstorz.com","sentAt":"2016-03-22T08:00:13Z","receivedAt":"2016-03-22T08:00:13Z","isPatch":false,"sender":{"key":"heiko.boettger@karlstorz.com","avatar":null},"body":"Hi,\n\nI 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.\n\nmessage 1:\n\nFetching origin\nerror: cannot lock ref 'refs/remotes/origin/branchname  Unable to create '/home/workingcopy/.git/refs/remotes/origin/ branchname.lock': File exists.\n\nIf no other git process is currently running, this probably means a\ngit process crashed in this repository earlier. Make sure no other git\nprocess is running and remove the file manually to continue.\nFrom servername:gitrepo\n! ccea072...349809e branchname  -> origin/branchname  (unable to update local ref)\nerror: Could not fetch origin\n\nmessage 2:\n\nerror: cannot lock ref 'refs/remotes/origin/master': ref refs/remotes/origin/master is at 07cd4a461229f9352d16063ff209e828cba592ea but expected 7c4ddcf998bad94f4f7e8e806baaa475f2069e60\n\nmessage 3 (on git pull --rebase):\n\nCannot rebase onto multiple branches\n\nDoes 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.\n\nAm 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?\n\nBest Regards\nHeiko Böttger\n"},{"id":"281424","messageId":"56F11467.3010004@web.de","threadId":"41776","inReplyTo":"8C0042D8869AEA4AA334B49AFBBCEF82B53CF505@TUT-EX02-PV.KSTG.corp","subject":"Re: git and concurrent access to local repository","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2016-03-22T09:46:15Z","receivedAt":"2016-03-22T09:46:15Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 2016-03-22 09.00, Boettger, Heiko wrote:\n> Hi,\n> \n> 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.\n> \nThat depends.\nconcurrent read only access should work, AFAIK.\nconcurrent read/write access (in the way I understand what you describe below)\nis not supported. (Well, that is my knowledge).\n\n> message 1:\n> \n> Fetching origin\n> error: cannot lock ref 'refs/remotes/origin/branchname  Unable to create '/home/workingcopy/.git/refs/remotes/origin/ branchname.lock': File exists.\n> \n> If no other git process is currently running, this probably means a\n> git process crashed in this repository earlier. Make sure no other git\n> process is running and remove the file manually to continue.\n> From servername:gitrepo\n> ! ccea072...349809e branchname  -> origin/branchname  (unable to update local ref)\n> error: Could not fetch origin\n> \n> message 2:\n> \n> error: cannot lock ref 'refs/remotes/origin/master': ref refs/remotes/origin/master is at 07cd4a461229f9352d16063ff209e828cba592ea but expected 7c4ddcf998bad94f4f7e8e806baaa475f2069e60\n> \n> message 3 (on git pull --rebase):\n> \n> Cannot rebase onto multiple branches\n> \n> 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.\n> \nThe whole scenario does make little sense to me.\nOne user/process/shell script should update one work tree,\nlike fetch/pull/rebase. After that, the build is started.\nThis has nothing to do with NFS, it's more that it is clear,\nwhat is done in which order, and to have things reproducible.\n\nlike\n- fetch\n- checkout\n- make\n- test.\n\nHow does the scenario work, that you want to achieve ?\n\nAnd why and how are multiple users/processes work in the same directory ?\n\n\n> Am I doing something wrong or is it concurrent access just not support this way? \n> Does that mean I have to use my own locks such as putting flock around each call?\nI'm not sure, if I understand the scenario completely.\nIt looks, as if different processes share one work tree,\nas if 2 persons share one keyboard, one doing lets say C-programming,\nand the other is doing some shell script development. At the same time.\nUsing the same keyboard.\n\nI don't know, if flock will help you, but I may miss something.\n> \n> Best Regards\n> Heiko Böttger\n"},{"id":"281520","messageId":"8C0042D8869AEA4AA334B49AFBBCEF82B53CF604@TUT-EX02-PV.KSTG.corp","threadId":"41776","inReplyTo":"56F14E7F.3010801@web.de","subject":"AW: AW: git and concurrent access to local repository","fromName":"Boettger, Heiko","fromEmail":"heiko.boettger@karlstorz.com","sentAt":"2016-03-23T07:08:22Z","receivedAt":"2016-03-23T07:08:22Z","isPatch":false,"sender":{"key":"heiko.boettger@karlstorz.com","avatar":null},"body":"Hi Torsten,\n\nyes, indeed I accidently pressed the wrong reply button.\n\nThe solution I'm using is the following:\n\npushd workingcopy > /dev/null\n\t(\n\t\tflock -x 200\n\t\tgit reset --hard\n\t\tgit clean -xfd\n\t\tgit pull --rebase\n\t) 200>.git/gitrebase.lock\npopd > /dev/null\n\nBest Regards\nHeiko\n\n-----Ursprüngliche Nachricht-----\nVon: Torsten Bögershausen [mailto:tboegi@web.de] \nGesendet: Dienstag, 22. März 2016 14:54\nAn: Boettger, Heiko\nBetreff: Re: AW: git and concurrent access to local repository\n\nThanks for the reply,\nyou may want to send it to all, including the git mailing list.\nThese kindof problems arise from time to time, and it may be nice to share your knowledge as well, including work-arounds\n\n\nOn 2016-03-22 10.54, Boettger, Heiko wrote:\n> Thanks Torsten,\n>\n> for sharing your knowledge. That exactly what I thought. As a solution, I'm guarding the calls with \"flock -x\", which perfectly works since I know exactly where the repos are used. \n>\n> Regards\n> Heiko\n"}]}