{"thread":{"id":"32653","subject":"Re: Question re. git remote repository","startedAt":"2013-01-16T23:32:09Z","lastAt":"2013-01-17T02:49:12Z","messageCount":8,"participants":["Matt Seitz (matseitz)","David Lang"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"207119","messageId":"A0DB01D693D8EF439496BC8B037A0AEF322098A4@xmb-rcd-x15.cisco.com","threadId":"32653","inReplyTo":null,"subject":"Re: Question re. git remote repository","fromName":"Matt Seitz (matseitz)","fromEmail":"matseitz@cisco.com","sentAt":"2013-01-16T23:32:09Z","receivedAt":"2013-01-16T23:32:09Z","isPatch":false,"sender":{"key":"matseitz@cisco.com","avatar":null},"body":"\"David Lang\" <david@lang.hm> wrote in message news:<alpine.DEB.2.02.1301161459060.21503@nftneq.ynat.uz>...\n> But if you try to have one filesystem, with multiple people running git on their \n> machines against that shared filesystem, I would expect you to have all sorts of \n> problems.\n\nWhat leads you to think you will have problems?\n\nWhy would there be more of a problem on a network file system as opposed to local file system that can be accessed by multiple users?\n\nLinus seemed to think it should work:\n\nhttp://permalink.gmane.org/gmane.comp.version-control.git/122670\n\nAnd \"git init\" specifically has a \"shared\" option:\n\n--shared[=(false|true|umask|group|all|world|everybody|0xxx)] \nSpecify that the git repository is to be shared amongst several users. This allows users belonging to the same group to push into that repository. When specified, the config variable \"core.sharedRepository\" is set so that files and directories under $GIT_DIR are created with the requested permissions. When not specified, git will use permissions reported by umask(2). \n"},{"id":"207122","messageId":"alpine.DEB.2.02.1301161617240.21503@nftneq.ynat.uz","threadId":"32653","inReplyTo":"A0DB01D693D8EF439496BC8B037A0AEF322098A4@xmb-rcd-x15.cisco.com","subject":"Re: Question re. git remote repository","fromName":"David Lang","fromEmail":"david@lang.hm","sentAt":"2013-01-17T00:21:41Z","receivedAt":"2013-01-17T00:21:41Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Wed, 16 Jan 2013, Matt Seitz (matseitz) wrote:\n\n> \"David Lang\" <david@lang.hm> wrote in message news:<alpine.DEB.2.02.1301161459060.21503@nftneq.ynat.uz>...\n>> But if you try to have one filesystem, with multiple people running git on their\n>> machines against that shared filesystem, I would expect you to have all sorts of\n>> problems.\n>\n> What leads you to think you will have problems?\n>\n> Why would there be more of a problem on a network file system as opposed to \n> local file system that can be accessed by multiple users?\n\nThere are safety checks and synchronization primitives that work between \nmulitiple users on one machine (where you can see what other processes are \nrunning for example) that don't work with separate machines using a filesystem\n\n> Linus seemed to think it should work:\n>\n> http://permalink.gmane.org/gmane.comp.version-control.git/122670\n\nwell, he knows git better than I do, but using git over NFS/CIFS is not the same \nas saying that you have multiple users on different systems making changes.\n\nIn the link you point at, he says that you can have problems with some types of \nactions. He points out things like git prune, but I would also say that there \nare probably race conditions if you have two git processes that try to change \nthe HEAD to different things at the same time.\n\n> And \"git init\" specifically has a \"shared\" option:\n>\n> --shared[=(false|true|umask|group|all|world|everybody|0xxx)]\n>\n> Specify that the git repository is to be shared amongst several users. This \n> allows users belonging to the same group to push into that repository. When \n> specified, the config variable \"core.sharedRepository\" is set so that files \n> and directories under $GIT_DIR are created with the requested permissions. \n> When not specified, git will use permissions reported by umask(2).\n>\n\nI think this is dealing with multiple users _reading_ a repository, not making \nupdates to it at the same time.\n\nDavid Lang\n"},{"id":"207126","messageId":"A0DB01D693D8EF439496BC8B037A0AEF32209A54@xmb-rcd-x15.cisco.com","threadId":"32653","inReplyTo":"alpine.DEB.2.02.1301161617240.21503@nftneq.ynat.uz","subject":"RE: Question re. git remote repository","fromName":"Matt Seitz (matseitz)","fromEmail":"matseitz@cisco.com","sentAt":"2013-01-17T01:09:00Z","receivedAt":"2013-01-17T01:09:00Z","isPatch":false,"sender":{"key":"matseitz@cisco.com","avatar":null},"body":"> From: David Lang [mailto:david@lang.hm]\n> \n> On Wed, 16 Jan 2013, Matt Seitz (matseitz) wrote:\n> \n> > Linus seemed to think it should work:\n> >\n> > http://permalink.gmane.org/gmane.comp.version-control.git/122670\n> \n> In the link you point at, he says that you can have problems with some\n> types of\n> actions. He points out things like git prune, \n\nLinus wrote:\n\nYou do need to be a bit careful if you do maintenance operations \nconcurrently (I would suggest avoiding doing concurrent \"git gc --prune\", \nfor example), but any normal git workflow should be fine.\n\n> but I would also say that there\n> are probably race conditions if you have two git processes that try to\n> change the HEAD to different things at the same time.\n\nWhat makes you think there are race conditions?\n\nLinus wrote:\n\nAnd git doesn't have \"proper locking\", because it doesn't need it for \ndatabase ops: git objects are stable. For refs, git should be using the \nproper NFS-safe \"create and atomic rename\" ops.\n\n> > And \"git init\" specifically has a \"shared\" option:\n> >\n> > --shared[=(false|true|umask|group|all|world|everybody|0xxx)]\n> \n> I think this is dealing with multiple users _reading_ a repository, not\n> making\n> updates to it at the same time.\n\nThe description of \"shared\" says \"This allows users belonging to the same group to push into that repository.\"  The \"push\" command is about making updates.\n"},{"id":"207127","messageId":"alpine.DEB.2.02.1301161721110.21503@nftneq.ynat.uz","threadId":"32653","inReplyTo":"A0DB01D693D8EF439496BC8B037A0AEF32209A54@xmb-rcd-x15.cisco.com","subject":"RE: Question re. git remote repository","fromName":"David Lang","fromEmail":"david@lang.hm","sentAt":"2013-01-17T01:26:13Z","receivedAt":"2013-01-17T01:26:13Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Thu, 17 Jan 2013, Matt Seitz (matseitz) wrote:\n\n>> From: David Lang [mailto:david@lang.hm]\n>>\n>> On Wed, 16 Jan 2013, Matt Seitz (matseitz) wrote:\n>>\n>>> Linus seemed to think it should work:\n>>>\n>>> http://permalink.gmane.org/gmane.comp.version-control.git/122670\n>>\n>> In the link you point at, he says that you can have problems with some\n>> types of\n>> actions. He points out things like git prune,\n>\n> Linus wrote:\n>\n> You do need to be a bit careful if you do maintenance operations\n> concurrently (I would suggest avoiding doing concurrent \"git gc --prune\",\n> for example), but any normal git workflow should be fine.\n>\n>> but I would also say that there\n>> are probably race conditions if you have two git processes that try to\n>> change the HEAD to different things at the same time.\n>\n> What makes you think there are race conditions?\n>\n> Linus wrote:\n>\n> And git doesn't have \"proper locking\", because it doesn't need it for\n> database ops: git objects are stable. For refs, git should be using the\n> proper NFS-safe \"create and atomic rename\" ops.\n\nAs Linus points out, objects are stable, so when you create objects you don't \nhave to worry about locking, if two things write an object at the same time, the \nsame contents are being written so races don't matter.\n\nHowever, if you have two people doing a commit or merge, you will get different \nresults based on the order they are happening in. This seems to be exactly the \ntype of thing that falls into the 'maintinance operations' category.\n\nLinus says that git does not have \"proper locking\", so think about it, what do \nyou think will happen if person A does git add a/b; git commit and person B does \ngit add c/d; git commit?\n\nSince the tree will look different depending on what order these four commands \nexecute in, the resulting HEAD could have multiple different values depending on \nthe order. The individual commits may even be different.\n\nDavid Lang\n\n>>> And \"git init\" specifically has a \"shared\" option:\n>>>\n>>> --shared[=(false|true|umask|group|all|world|everybody|0xxx)]\n>>\n>> I think this is dealing with multiple users _reading_ a repository, not\n>> making\n>> updates to it at the same time.\n>\n> The description of \"shared\" says \"This allows users belonging to the same \n> group to push into that repository.\"  The \"push\" command is about making \n> updates.\n"},{"id":"207128","messageId":"A0DB01D693D8EF439496BC8B037A0AEF32209AD2@xmb-rcd-x15.cisco.com","threadId":"32653","inReplyTo":"alpine.DEB.2.02.1301161721110.21503@nftneq.ynat.uz","subject":"RE: Question re. git remote repository","fromName":"Matt Seitz (matseitz)","fromEmail":"matseitz@cisco.com","sentAt":"2013-01-17T01:46:07Z","receivedAt":"2013-01-17T01:46:07Z","isPatch":false,"sender":{"key":"matseitz@cisco.com","avatar":null},"body":"> From: David Lang [mailto:david@lang.hm]\n> \n> Linus says that git does not have \"proper locking\", so think about it,\n> what do\n> you think will happen if person A does git add a/b; git commit and person\n> B does\n> git add c/d; git commit?\n\nSorry, I wasn't clear. My assumption is that a shared repository on a network file system will either be: \n\n1. a bare repository that is normally accessed only by \"git push\" and \"git pull\" (or \"git fetch\"), the central repository model.\n\n2. a repository where only one user does \"git add\" and \"git commit\", while other users will do \"git pull\", the peer-to-peer model (you pull changes from me, I pull changes from you).\n"},{"id":"207129","messageId":"alpine.DEB.2.02.1301161756240.21503@nftneq.ynat.uz","threadId":"32653","inReplyTo":"A0DB01D693D8EF439496BC8B037A0AEF32209AD2@xmb-rcd-x15.cisco.com","subject":"RE: Question re. git remote repository","fromName":"David Lang","fromEmail":"david@lang.hm","sentAt":"2013-01-17T01:59:54Z","receivedAt":"2013-01-17T01:59:54Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Thu, 17 Jan 2013, Matt Seitz (matseitz) wrote:\n\n>> From: David Lang [mailto:david@lang.hm]\n>>\n>> Linus says that git does not have \"proper locking\", so think about it,\n>> what do\n>> you think will happen if person A does git add a/b; git commit and person\n>> B does\n>> git add c/d; git commit?\n>\n> Sorry, I wasn't clear. My assumption is that a shared repository on a network file system will either be:\n>\n> 1. a bare repository that is normally accessed only by \"git push\" and \"git pull\" (or \"git fetch\"), the central repository model.\n\npulling from it would not be a problem, I could see issues with multiple pushes \ntaking place (the underlying repository would not get corrupted, but you will \nvery quickly hit conflicts where the push is not a fast forward and you need to \nmerge, not just push)\n\n> 2. a repository where only one user does \"git add\" and \"git commit\", while \n> other users will do \"git pull\", the peer-to-peer model (you pull changes from \n> me, I pull changes from you).\n\nAt this point only one system is writing to the repository and it doesn't matter \nthat it's on network storage vs local storage.\n\npulling from a shared repository is probably safe, but I wouldn't bet against \nthere being any conditions where a pull at the same time someone is doing an \nupdate being able to cause problems.\n\nThe normal thing is to do the pulls through git-daemon, and that does make sure \nthat what you are pulling is consistant.\n\nDavid Lang\n"},{"id":"207131","messageId":"A0DB01D693D8EF439496BC8B037A0AEF32209B45@xmb-rcd-x15.cisco.com","threadId":"32653","inReplyTo":"alpine.DEB.2.02.1301161756240.21503@nftneq.ynat.uz","subject":"RE: Question re. git remote repository","fromName":"Matt Seitz (matseitz)","fromEmail":"matseitz@cisco.com","sentAt":"2013-01-17T02:25:26Z","receivedAt":"2013-01-17T02:25:26Z","isPatch":false,"sender":{"key":"matseitz@cisco.com","avatar":null},"body":"> From: David Lang [mailto:david@lang.hm]\n> \n> On Thu, 17 Jan 2013, Matt Seitz (matseitz) wrote:\n> \n> > 1. a bare repository that is normally accessed only by \"git push\" and\n> > \"git pull\" (or \"git fetch\"), the central repository model.\n> \n> pulling from it would not be a problem, I could see issues with multiple\n> pushes taking place (the underlying repository would not get corrupted, but you\n> will very quickly hit conflicts where the push is not a fast forward and you\n> need to merge, not just push)\n\nHow is that different on a network file system, as opposed to using http, ssh, or git-daemon?  Don't you get a \"not a fast-forward\" error, regardless of the protocol?\n\n> > 2. a repository where only one user does \"git add\" and \"git commit\",\n> while\n> > other users will do \"git pull\", the peer-to-peer model (you pull changes\n> from\n> > me, I pull changes from you).\n> \n> \n> pulling from a shared repository is probably safe, but I wouldn't bet\n> against\n> there being any conditions where a pull at the same time someone is doing\n> an\n> update being able to cause problems.\n\nWhy do you think there would be a problem?\n\n> The normal thing is to do the pulls through git-daemon, and that does make\n> sure\n> that what you are pulling is consistant.\n\nWhat does \"git pull\" via git-daemon do to ensure consistency that is different from \"git pull\" on a network file system?\n"},{"id":"207132","messageId":"alpine.DEB.2.02.1301161843390.21503@nftneq.ynat.uz","threadId":"32653","inReplyTo":"A0DB01D693D8EF439496BC8B037A0AEF32209B45@xmb-rcd-x15.cisco.com","subject":"RE: Question re. git remote repository","fromName":"David Lang","fromEmail":"david@lang.hm","sentAt":"2013-01-17T02:49:12Z","receivedAt":"2013-01-17T02:49:12Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Thu, 17 Jan 2013, Matt Seitz (matseitz) wrote:\n\n>> From: David Lang [mailto:david@lang.hm]\n>>\n>> On Thu, 17 Jan 2013, Matt Seitz (matseitz) wrote:\n>>\n>>> 1. a bare repository that is normally accessed only by \"git push\" and\n>>> \"git pull\" (or \"git fetch\"), the central repository model.\n>>\n>> pulling from it would not be a problem, I could see issues with multiple\n>> pushes taking place (the underlying repository would not get corrupted, but you\n>> will very quickly hit conflicts where the push is not a fast forward and you\n>> need to merge, not just push)\n>\n> How is that different on a network file system, as opposed to using http, ssh, or git-daemon?  Don't you get a \"not a fast-forward\" error, regardless of the protocol?\n\ntrue.\n\n>>> 2. a repository where only one user does \"git add\" and \"git commit\",\n>> while\n>>> other users will do \"git pull\", the peer-to-peer model (you pull changes\n>> from\n>>> me, I pull changes from you).\n>>\n>>\n>> pulling from a shared repository is probably safe, but I wouldn't bet\n>> against\n>> there being any conditions where a pull at the same time someone is doing\n>> an\n>> update being able to cause problems.\n>\n> Why do you think there would be a problem?\n>\n>> The normal thing is to do the pulls through git-daemon, and that does make\n>> sure\n>> that what you are pulling is consistant.\n>\n> What does \"git pull\" via git-daemon do to ensure consistency that is different from \"git pull\" on a network file system?\n\ngit pull via the daemon looks at what tree items you have on each end, and then \nit sends you the items needed to make you match the server. If there are partial \nupdates on the server (due to some update in process) the daemon should not see \nthat, but if you are grabbing the files directly, I would be less confident that \nyou are always safe.\n\nyou may _be_ safe, and if others who really know the internals speak up, take \ntheir word on it. But, absent assurances that we know that everything is done in \nthe right order in the face of a networked filesystem (which may break \nvisibility of changes due to caching), I would not trust such raw access for \nupdates at all, and only somewhat trust it for read-only use.\n\nDavid Lang\n"}]}