{"thread":{"id":"32651","subject":"Question re. git remote repository","startedAt":"2013-01-16T17:49:09Z","lastAt":"2013-01-23T20:24:43Z","messageCount":21,"participants":["Lang, David","Konstantin Khomoutov","Jeff King","David Lang","Stephen Smith","Matt Seitz","Junio C Hamano","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"207077","messageId":"201301161749.r0GHnGV6007806@smtpb02.one-mail.on.ca","threadId":"32651","inReplyTo":null,"subject":"Question re. git remote repository","fromName":"Lang, David","fromEmail":"david.lang@uhn.ca","sentAt":"2013-01-16T17:49:09Z","receivedAt":"2013-01-16T17:49:09Z","isPatch":false,"sender":{"key":"david.lang@uhn.ca","avatar":null},"body":"Hello,\n\nWe're just in the process of investigating a versioning tool and are very interesting in git. We have one question we're hoping someone can answer. In regards to the repositories, I think I understand correctly that each developer will have a local repository that they will work from, and that there will also be a remote repository (origin) that will hold the original version of the project.\n\nIt appears from the limited reading I've done that the remote repository must be hosted at github.com. Is this the case? Ideally we'd prefer to simply create our remote repository on a drive of one of our local network servers. Is this possible?\n\nThanks in advance for the help.\n\nDavid Lang | Application Developer | Tel: 416-340-4800 x.5277\nCardiac IT Dept - Toronto General Hospital\nThe University Health Network\n200 Elizabeth St.\nToronto, ON   M5G 2C4\n\n\nThis e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. \nAny review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. \nIf you have received this e-mail in error, please contact the sender and delete all copies. \nOpinions, conclusions or other information contained in this e-mail may not be that of the organization.\n"},{"id":"207082","messageId":"20130116220615.48c159546bccfa5b9cd9028e@domain007.com","threadId":"32651","inReplyTo":"201301161749.r0GHnGV6007806@smtpb02.one-mail.on.ca","subject":"Re: Question re. git remote repository","fromName":"Konstantin Khomoutov","fromEmail":"kostix+git@007spb.ru","sentAt":"2013-01-16T18:06:15Z","receivedAt":"2013-01-16T18:06:15Z","isPatch":false,"sender":{"key":"kostix+git@007spb.ru","avatar":null},"body":"On Wed, 16 Jan 2013 17:49:09 +0000\n\"Lang, David\" <David.Lang@uhn.ca> wrote:\n\n> We're just in the process of investigating a versioning tool and are\n> very interesting in git. We have one question we're hoping someone\n> can answer. In regards to the repositories, I think I understand\n> correctly that each developer will have a local repository that they\n> will work from, and that there will also be a remote repository\n> (origin) that will hold the original version of the project.\n\nThe name \"origin\" is purely arbitrary: any local repository might have\n\n> It appears from the limited reading I've done that the remote\n> repository must be hosted at github.com. Is this the case?\nOf course not.  github is just a Git hosting provider.  There are\nplenty of them -- both commercial and not-for-profit (a well-known\nservice bitbucket.org is one example).\n\n> Ideally we'd prefer to simply create our remote repository on a drive\n> of one of our local network servers. Is this possible?\n\nYes, this is possible, but it's not advised to keep such a \"reference\"\nrepository on an exported networked drive for a number of reasons (both\nperformance and bug-free operation).\n\nInstead, the canonical way to host \"reference\" repositories is to make\nthem accessible via SSH or via HTTP[S].  To do this, a server running\nsome POSIX OS (Linux- or *BSD-based) is the best bet.  Both kinds of\naccess require Git itself installed on the server.  Obviously, SSH\naccess requires an SSH server software (such as OpenSSH) as well and\nHTTP[S] access requires a web server (such as Apache).  Of course,\neverything mentioned is available on any sensible OS you might install\non your server.  Read-only access might be provided by a special tool\nnamed \"Git daemon\" which is a part of Git.\n\nIf you have more than a couple of developers you might want to install\ncertain front-end Git software on the server which provides for\n\"virtualized\" Git users and fine-grained control over who can do what.\nUsing gitolite [3] for this is the current trend.\n\nWeb-browsing for your repositories, if needed, is usually provided by\nthe tool named gitweb [4].\n\nEverything I've just summarised is well explained in [5] and [6] (as an\naddendum).\n\nAnother approach is to set up a \"turn-key\" solution such as GitLab [1]\nor gitblit [2].\n\n1. http://gitlabhq.com/\n2. http://gitblit.com/\n3. https://github.com/sitaramc/gitolite\n4. https://git.wiki.kernel.org/index.php/Gitweb\n5. http://git-scm.com/book/en/Git-on-the-Server\n6. http://git-scm.com/2010/03/04/smart-http.html\n"},{"id":"207089","messageId":"20130116182156.GB4426@sigill.intra.peff.net","threadId":"32651","inReplyTo":"20130116220615.48c159546bccfa5b9cd9028e@domain007.com","subject":"Re: Question re. git remote repository","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-01-16T18:21:56Z","receivedAt":"2013-01-16T18:21:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jan 16, 2013 at 10:06:15PM +0400, Konstantin Khomoutov wrote:\n\n> > In regards to the repositories, I think I understand correctly that\n> > each developer will have a local repository that they will work\n> > from, and that there will also be a remote repository (origin) that\n> > will hold the original version of the project.\n\nNote that this is just one common topology for setting up repos (and it\nis probably the simplest). Others are described here:\n\n  http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows\n\n> > Ideally we'd prefer to simply create our remote repository on a drive\n> > of one of our local network servers. Is this possible?\n> \n> Yes, this is possible, but it's not advised to keep such a \"reference\"\n> repository on an exported networked drive for a number of reasons (both\n> performance and bug-free operation).\n\nI agree that performance is not ideal (although if you are on a fast\nLAN, it probably would not matter much), but I do not recall any\nspecific bugs in that area. Can you elaborate?\n\n-Peff\n"},{"id":"207099","messageId":"20130116233744.7d0775eaec98ce154a9de180@domain007.com","threadId":"32651","inReplyTo":"20130116182156.GB4426@sigill.intra.peff.net","subject":"Re: Question re. git remote repository","fromName":"Konstantin Khomoutov","fromEmail":"kostix+git@007spb.ru","sentAt":"2013-01-16T19:37:44Z","receivedAt":"2013-01-16T19:37:44Z","isPatch":false,"sender":{"key":"kostix+git@007spb.ru","avatar":null},"body":"On Wed, 16 Jan 2013 10:21:56 -0800\nJeff King <peff@peff.net> wrote:\n\nThanks for elaborating on the \"origin\" -- I intended to write up on its\nspecial status but got distracted and sent my message missing that\nbit ;-)\n\n[...]\n> > > Ideally we'd prefer to simply create our remote repository on a\n> > > drive of one of our local network servers. Is this possible?\n> > \n> > Yes, this is possible, but it's not advised to keep such a\n> > \"reference\" repository on an exported networked drive for a number\n> > of reasons (both performance and bug-free operation).\n> \n> I agree that performance is not ideal (although if you are on a fast\n> LAN, it probably would not matter much), but I do not recall any\n> specific bugs in that area. Can you elaborate?\n\nThis one [1] for instance.  I also recall seing people having other\n\"mystical\" problems with setups like this so I somehow developed an idea\nthan having a repository on a networked drive is asking for troubles.\nOf course, if there are happy users of such setups, I would be glad to\nhear as my precautions might well be unfounded for the recent versions\nof Git.\n\n1. http://code.google.com/p/msysgit/issues/detail?id=130\n"},{"id":"207101","messageId":"alpine.DEB.2.02.1301161202390.21503@nftneq.ynat.uz","threadId":"32651","inReplyTo":"201301161749.r0GHnGV6007806@smtpb02.one-mail.on.ca","subject":"Re: Question re. git remote repository","fromName":"David Lang","fromEmail":"david@lang.hm","sentAt":"2013-01-16T20:07:47Z","receivedAt":"2013-01-16T20:07:47Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"Hi David, now we are going to have some confusion here, two David Langs on the \nlist :-)\n\nOn Wed, 16 Jan 2013, Lang, David wrote:\n\n> We're just in the process of investigating a versioning tool and are very \n> interesting in git. We have one question we're hoping someone can answer. In \n> regards to the repositories, I think I understand correctly that each \n> developer will have a local repository that they will work from, and that \n> there will also be a remote repository (origin) that will hold the original \n> version of the project.\n>\n> It appears from the limited reading I've done that the remote repository must \n> be hosted at github.com. Is this the case? Ideally we'd prefer to simply \n> create our remote repository on a drive of one of our local network servers. \n> Is this possible?\n\nGit is peer-to-peer, the 'origin' is just the default to pull from. It can be \nhosted on any machine that you have access to.\n\nA typical case is that you designate one person (or a small group of people) \nto oversee your master repository, and that person decides when and what to pull \nthere from the developers.\n\nThis gives you a chance to insert code review, tests, etc between what the \ndevelopers produce in their local repository and what you then bless as the \nauthoritative 'released' version of the code.\n\nHowever, this master repository is just a matter of convention, it is possible \nto use any repository as the 'origin', changing it is just a config change away.\n\nDavid Lang\n"},{"id":"207113","messageId":"0630A778-9AC8-4023-889C-4FC58ABAB683@gmail.com","threadId":"32651","inReplyTo":"20130116233744.7d0775eaec98ce154a9de180@domain007.com","subject":"Re: Question re. git remote repository","fromName":"Stephen Smith","fromEmail":"ishchis2@gmail.com","sentAt":"2013-01-16T22:59:04Z","receivedAt":"2013-01-16T22:59:04Z","isPatch":false,"sender":{"key":"ishchis2@gmail.com","avatar":null},"body":"\n>>>> Ideally we'd prefer to simply create our remote repository on a\n>>>> drive of one of our local network servers. Is this possible?\n>>> \n>>> Yes, this is possible, but it's not advised to keep such a\n>>> \"reference\" repository on an exported networked drive for a number\n>>> of reasons (both performance and bug-free operation).\n>> \n>> I agree that performance is not ideal (although if you are on a fast\n>> LAN, it probably would not matter much), but I do not recall any\n>> specific bugs in that area. Can you elaborate?\n> \n> This one [1] for instance.  I also recall seing people having other\n> \"mystical\" problems with setups like this so I somehow developed an idea\n> than having a repository on a networked drive is asking for troubles.\n> Of course, if there are happy users of such setups, I would be glad to\n> hear as my precautions might well be unfounded for the recent versions\n> of Git.\n> \n> 1. http://code.google.com/p/msysgit/issues/detail?id=130\n\nA group I was with used a master repository on a windows share for quite some time without a database corruption being seen.   "},{"id":"207114","messageId":"alpine.DEB.2.02.1301161459060.21503@nftneq.ynat.uz","threadId":"32651","inReplyTo":"0630A778-9AC8-4023-889C-4FC58ABAB683@gmail.com","subject":"Re: Question re. git remote repository","fromName":"David Lang","fromEmail":"david@lang.hm","sentAt":"2013-01-16T23:00:41Z","receivedAt":"2013-01-16T23:00:41Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Wed, 16 Jan 2013, Stephen Smith wrote:\n\n>>>>> Ideally we'd prefer to simply create our remote repository on a\n>>>>> drive of one of our local network servers. Is this possible?\n>>>>\n>>>> Yes, this is possible, but it's not advised to keep such a\n>>>> \"reference\" repository on an exported networked drive for a number\n>>>> of reasons (both performance and bug-free operation).\n>>>\n>>> I agree that performance is not ideal (although if you are on a fast\n>>> LAN, it probably would not matter much), but I do not recall any\n>>> specific bugs in that area. Can you elaborate?\n>>\n>> This one [1] for instance.  I also recall seing people having other\n>> \"mystical\" problems with setups like this so I somehow developed an idea\n>> than having a repository on a networked drive is asking for troubles.\n>> Of course, if there are happy users of such setups, I would be glad to\n>> hear as my precautions might well be unfounded for the recent versions\n>> of Git.\n>>\n>> 1. http://code.google.com/p/msysgit/issues/detail?id=130\n>\n> A group I was with used a master repository on a windows share for quite some time without a database corruption being seen.   --\n\nI think the risk is that if you have multiple people doing actions on the shared \nfilesystem you can run into trouble.\n\nAs long as only one copy of git is ever running against the repository, I don't \nsee any reason for there to be a problem.\n\nBut if you try to have one filesystem, with multiple people running git on their \nmachines against that shared filesystem, I would expect you to have all sorts of \nproblems.\n\nDavid Lang\n"},{"id":"207174","messageId":"201301172153.r0HLrU4F019815@smtpb02.one-mail.on.ca","threadId":"32651","inReplyTo":"alpine.DEB.2.02.1301161459060.21503@nftneq.ynat.uz","subject":"RE: Question re. git remote repository","fromName":"Lang, David","fromEmail":"david.lang@uhn.ca","sentAt":"2013-01-17T21:53:29Z","receivedAt":"2013-01-17T21:53:29Z","isPatch":false,"sender":{"key":"david.lang@uhn.ca","avatar":null},"body":"Hi David,\n\nOk, now I'm really lost! This is definitely due to my newbie git status but I'll ask anyway. I'm confused by your statement \"... if you try to have one filesystem, with multiple people running git on their machines against that shared filesystem, I would expect you to have all sorts of problems.\"\n\nIsn't that the whole point of git, or any versioning system? I thought the idea was that each developer installed git locally on their machines and (as needed) committed their changes to the master repository which resides externally to any of the local machines, such as on a network server (and which I'm assuming has git installed locally as well).\n\nWhat am I missing?\n\nThe 'other' David Lang   ;-)\n\n-----Original Message-----\nFrom: David Lang [mailto:david@lang.hm] \nSent: Wednesday, January 16, 2013 6:01 PM\nTo: Stephen Smith\nCc: Konstantin Khomoutov; Jeff King; git@vger.kernel.org; Lang, David\nSubject: Re: Question re. git remote repository\n\nOn Wed, 16 Jan 2013, Stephen Smith wrote:\n\n>>>>> Ideally we'd prefer to simply create our remote repository on a \n>>>>> drive of one of our local network servers. Is this possible?\n>>>>\n>>>> Yes, this is possible, but it's not advised to keep such a \n>>>> \"reference\" repository on an exported networked drive for a number \n>>>> of reasons (both performance and bug-free operation).\n>>>\n>>> I agree that performance is not ideal (although if you are on a fast \n>>> LAN, it probably would not matter much), but I do not recall any \n>>> specific bugs in that area. Can you elaborate?\n>>\n>> This one [1] for instance.  I also recall seing people having other \n>> \"mystical\" problems with setups like this so I somehow developed an \n>> idea than having a repository on a networked drive is asking for troubles.\n>> Of course, if there are happy users of such setups, I would be glad \n>> to hear as my precautions might well be unfounded for the recent \n>> versions of Git.\n>>\n>> 1. http://code.google.com/p/msysgit/issues/detail?id=130\n>\n> A group I was with used a master repository on a windows share for quite some time without a database corruption being seen.   --\n\nI think the risk is that if you have multiple people doing actions on the shared filesystem you can run into trouble.\n\nAs long as only one copy of git is ever running against the repository, I don't see any reason for there to be a problem.\n\nBut if you try to have one filesystem, with multiple people running git on their machines against that shared filesystem, I would expect you to have all sorts of problems.\n\nDavid Lang\n\nThis e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. \nAny review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. \nIf you have received this e-mail in error, please contact the sender and delete all copies. \nOpinions, conclusions or other information contained in this e-mail may not be that of the organization.\n"},{"id":"207182","messageId":"alpine.DEB.2.02.1301171514530.21503@nftneq.ynat.uz","threadId":"32651","inReplyTo":"201301172153.r0HLrUIr001039@smtpb01.one-mail.on.ca","subject":"RE: Question re. git remote repository","fromName":"David Lang","fromEmail":"david@lang.hm","sentAt":"2013-01-17T23:19:26Z","receivedAt":"2013-01-17T23:19:26Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"distributed version control systems let each developer have a full repository \nlocally on their machine, they then can send updates to other people who have a \nrepository (or a pull request which asks the other person to pull from the \ndevelopers repository to the other persons repository)\n\nMost projects have one repository that they designate as being the 'main' \nrepository for the project, and developers push updates to it (or send pull \nrequests to the people who own that repository)\n\nThe communication between developers is typically via e-mail and the repository \nupdates are sent via the git-daemon and the git network protocol.\n\n\n\nThis sort of thing is very different from the model where there is one \nrepository on a shared disk somewhere and everyone accesses that shared disk to \ndo their work or apply updates via NFS/CIFS protocols.\n\nDoes this clarify the difference?\n\nDavid Lang\n\nOn Thu, 17 Jan 2013, Lang, David wrote:\n\n> Hi David,\n>\n> Ok, now I'm really lost! This is definitely due to my newbie git status but \n> I'll ask anyway. I'm confused by your statement \"... if you try to have one \n> filesystem, with multiple people running git on their machines against that \n> shared filesystem, I would expect you to have all sorts of problems.\"\n>\n> Isn't that the whole point of git, or any versioning system? I thought the \n> idea was that each developer installed git locally on their machines and (as \n> needed) committed their changes to the master repository which resides \n> externally to any of the local machines, such as on a network server (and \n> which I'm assuming has git installed locally as well).\n>\n> What am I missing?\n>\n> The 'other' David Lang   ;-)\n>\n> -----Original Message-----\n> From: David Lang [mailto:david@lang.hm]\n> Sent: Wednesday, January 16, 2013 6:01 PM\n> To: Stephen Smith\n> Cc: Konstantin Khomoutov; Jeff King; git@vger.kernel.org; Lang, David\n> Subject: Re: Question re. git remote repository\n>\n> On Wed, 16 Jan 2013, Stephen Smith wrote:\n>\n>>>>>> Ideally we'd prefer to simply create our remote repository on a\n>>>>>> drive of one of our local network servers. Is this possible?\n>>>>>\n>>>>> Yes, this is possible, but it's not advised to keep such a\n>>>>> \"reference\" repository on an exported networked drive for a number\n>>>>> of reasons (both performance and bug-free operation).\n>>>>\n>>>> I agree that performance is not ideal (although if you are on a fast\n>>>> LAN, it probably would not matter much), but I do not recall any\n>>>> specific bugs in that area. Can you elaborate?\n>>>\n>>> This one [1] for instance.  I also recall seing people having other\n>>> \"mystical\" problems with setups like this so I somehow developed an\n>>> idea than having a repository on a networked drive is asking for troubles.\n>>> Of course, if there are happy users of such setups, I would be glad\n>>> to hear as my precautions might well be unfounded for the recent\n>>> versions of Git.\n>>>\n>>> 1. http://code.google.com/p/msysgit/issues/detail?id=130\n>>\n>> A group I was with used a master repository on a windows share for quite some time without a database corruption being seen.   --\n>\n> I think the risk is that if you have multiple people doing actions on the shared filesystem you can run into trouble.\n>\n> As long as only one copy of git is ever running against the repository, I don't see any reason for there to be a problem.\n>\n> But if you try to have one filesystem, with multiple people running git on their machines against that shared filesystem, I would expect you to have all sorts of problems.\n>\n> David Lang\n>\n> This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient.\n> Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited.\n> If you have received this e-mail in error, please contact the sender and delete all copies.\n> Opinions, conclusions or other information contained in this e-mail may not be that of the organization.\n>\n>\n"},{"id":"207183","messageId":"20130117234912.GA14936@sigill.intra.peff.net","threadId":"32651","inReplyTo":"alpine.DEB.2.02.1301161459060.21503@nftneq.ynat.uz","subject":"Re: Question re. git remote repository","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-01-17T23:49:13Z","receivedAt":"2013-01-17T23:49:13Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jan 16, 2013 at 03:00:41PM -0800, David Lang wrote:\n\n> >>This one [1] for instance.  I also recall seing people having other\n> >>\"mystical\" problems with setups like this so I somehow developed an idea\n> >>than having a repository on a networked drive is asking for troubles.\n> >>Of course, if there are happy users of such setups, I would be glad to\n> >>hear as my precautions might well be unfounded for the recent versions\n> >>of Git.\n> >>\n> >>1. http://code.google.com/p/msysgit/issues/detail?id=130\n> >\n> >A group I was with used a master repository on a windows share for quite some time without a database corruption being seen.   --\n> \n> I think the risk is that if you have multiple people doing actions on\n> the shared filesystem you can run into trouble.\n> \n> As long as only one copy of git is ever running against the\n> repository, I don't see any reason for there to be a problem.\n\nThat should not be an issue. Git on a server has to deal with multiple\nindependent receive-pack's running to accept several simultaneous\npushes. They coordinate through the use of file locks. Having multiple\nmachines pushing over a shared filesystem should work the same, as long\nas the filesystem support atomic creation of files with O_EXCL.\n\nThere may be other subtle issues lurking (e.g., the Windows issue that\nKonstantin mentioned), but as far as I know, it _should_ work in\ngeneral.\n\n-Peff\n"},{"id":"207196","messageId":"1BBEF94B6B46E54980290D150A6F2EDD46B7AAE2@BN1PRD0612MB635.namprd06.prod.outlook.com","threadId":"32651","inReplyTo":"201301172153.r0HLrU4F019815@smtpb02.one-mail.on.ca","subject":"RE: Question re. git remote repository","fromName":"Matt Seitz","fromEmail":"mseitz@mhseitz.onmicrosoft.com","sentAt":"2013-01-18T05:51:39Z","receivedAt":"2013-01-18T05:51:39Z","isPatch":false,"sender":{"key":"mseitz@mhseitz.onmicrosoft.com","avatar":null},"body":"From: git-owner@vger.kernel.org [git-owner@vger.kernel.org] on behalf of Lang, David [David.Lang@uhn.ca]\n\n> I thought the idea was that each developer installed git locally on their machines \n\nYes.\n\n> and (as needed) committed their changes to the master repository which resides externally to any of the local machines, such as on a network \n> server \n\nYes, but committing their changes to the master repository is a two step process:\n\n1.  Each developer first commits their changes to their personal repository using the \"git commit\" command.\n2.  Each developer pushes their changes from their personal repository to the master repository with the \"git push\" command\n\n> (and which I'm assuming has git installed locally as well).\n\nMaybe.\n\nIf the machine with the master repository has git installed locally, then each developer can push their changes to the master repository using either the git protocol or the ssh protocol.\n\nIf the machine with the master repository does not have git installed locally, then each developer can push their changes to the master repository using NFS or CIFS/SMB.  The git documentation refers to this method as the \"file protocol\".\n\nThe other David Lang (david@lang.hm) believes that using \"git push\" using NFS or CIFS/SMB may not be safe and reliable.  Based on the following article by the creator of git, I believe using \"git push\" over NFS or CIFS/SMB is safe and reliable:\n\nhttp://permalink.gmane.org/gmane.comp.version-control.git/122670\n\nThe GitFaq wiki also says that using \"git push\" over NFS or CIFS/SMB is safe and reliable:\n\nhttps://git.wiki.kernel.org/index.php/GitFaq#What_can_I_use_to_set_up_a_public_repository.3F\n"},{"id":"207197","messageId":"alpine.DEB.2.02.1301172216310.2151@nftneq.ynat.uz","threadId":"32651","inReplyTo":"1BBEF94B6B46E54980290D150A6F2EDD46B7AAE2@BN1PRD0612MB635.namprd06.prod.outlook.com","subject":"RE: Question re. git remote repository","fromName":"David Lang","fromEmail":"david@lang.hm","sentAt":"2013-01-18T06:18:42Z","receivedAt":"2013-01-18T06:18:42Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Fri, 18 Jan 2013, Matt Seitz wrote:\n\n> From: git-owner@vger.kernel.org [git-owner@vger.kernel.org] on behalf of Lang, David [David.Lang@uhn.ca]\n>\n> The other David Lang (david@lang.hm) believes that using \"git push\" using NFS or CIFS/SMB may not be safe and reliable.  Based on the following article by the creator of git, I believe using \"git push\" over NFS or CIFS/SMB is safe and reliable:\n>\n> http://permalink.gmane.org/gmane.comp.version-control.git/122670\n>\n> The GitFaq wiki also says that using \"git push\" over NFS or CIFS/SMB is safe and reliable:\n>\n> https://git.wiki.kernel.org/index.php/GitFaq#What_can_I_use_to_set_up_a_public_repository.3F\n\nI'm glad to learn that git is more robust than I feared.\n\nDavid Lang\n"},{"id":"207211","messageId":"201301181833.r0IIXNe7021768@smtpb01.one-mail.on.ca","threadId":"32651","inReplyTo":"1BBEF94B6B46E54980290D150A6F2EDD46B7AAE2@BN1PRD0612MB635.namprd06.prod.outlook.com","subject":"RE: Question re. git remote repository","fromName":"Lang, David","fromEmail":"david.lang@uhn.ca","sentAt":"2013-01-18T18:33:22Z","receivedAt":"2013-01-18T18:33:22Z","isPatch":false,"sender":{"key":"david.lang@uhn.ca","avatar":null},"body":"Hi Matt and David,\n\nYour responses have been very helpful for this newbie...thanks very much! I have a good sense now of the difference btw a CVCS and a DVCS. Here are two more questions...\n\n1. I now get the sense that there's quite a few options in regards to the way that any one group implements their \"origin\"/\"master\"/<fill in your favourite name> repository. But ultimately, there shouldn't be a question of \"if\" you have a master repository but \"where\" you have the master repository, correct? Or in other words, it doesn't seem like you'd want to designate any one developer's local repository as also being the master repository, right? My sense is that would defeat the purpose of the DVCS.\n\n2. Assuming I'm right about question #1, our first hurdle is where to host the master repository. Could you provide any suggestions for a setup based on our VERY simple department model? I work for a small IT department with a grand total of TWO developers (who sit five feet apart from one another)! The reason we're looking at a VCS is because I was hired a few months ago and the dept never needed one before now. We realize that git will be overkill for what we need but frankly anything will be overkill for what we need, and since git seems to be so well regarded in the community (and free) it looks like a good choice.\n\nSo the question is, how would either of you recommend we set up our master repository? We definitely want to keep everything \"in house\" so off-site hosting isn't something we'd consider. We have access to many servers on our company's network, some of which we have full rights to, so there's no issue in regards to storage space. I suppose another idea would be to have the master simply reside on one of the two developers local machines, so one of us would have both a local rep and the master rep and the other of us would have just a local rep. This would simplify the model. What do you think? Or is it best to always have the master hosted on a machine with no other local reps?\n\nDavid\n\n-----Original Message-----\nFrom: Matt Seitz [mailto:mseitz@mhseitz.onmicrosoft.com] \nSent: Friday, January 18, 2013 12:52 AM\nTo: Lang, David; David Lang\nCc: Konstantin Khomoutov; Jeff King; git@vger.kernel.org; Stephen Smith\nSubject: RE: Question re. git remote repository\n\nFrom: git-owner@vger.kernel.org [git-owner@vger.kernel.org] on behalf of Lang, David [David.Lang@uhn.ca]\n\n> I thought the idea was that each developer installed git locally on \n> their machines\n\nYes.\n\n> and (as needed) committed their changes to the master repository which \n> resides externally to any of the local machines, such as on a network \n> server\n\nYes, but committing their changes to the master repository is a two step process:\n\n1.  Each developer first commits their changes to their personal repository using the \"git commit\" command.\n2.  Each developer pushes their changes from their personal repository to the master repository with the \"git push\" command\n\n> (and which I'm assuming has git installed locally as well).\n\nMaybe.\n\nIf the machine with the master repository has git installed locally, then each developer can push their changes to the master repository using either the git protocol or the ssh protocol.\n\nIf the machine with the master repository does not have git installed locally, then each developer can push their changes to the master repository using NFS or CIFS/SMB.  The git documentation refers to this method as the \"file protocol\".\n\nThe other David Lang (david@lang.hm) believes that using \"git push\" using NFS or CIFS/SMB may not be safe and reliable.  Based on the following article by the creator of git, I believe using \"git push\" over NFS or CIFS/SMB is safe and reliable:\n\nhttp://permalink.gmane.org/gmane.comp.version-control.git/122670\n\nThe GitFaq wiki also says that using \"git push\" over NFS or CIFS/SMB is safe and reliable:\n\nhttps://git.wiki.kernel.org/index.php/GitFaq#What_can_I_use_to_set_up_a_public_repository.3F\n\nThis e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. \nAny review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. \nIf you have received this e-mail in error, please contact the sender and delete all copies. \nOpinions, conclusions or other information contained in this e-mail may not be that of the organization.\n"},{"id":"207222","messageId":"alpine.DEB.2.02.1301181127590.21503@nftneq.ynat.uz","threadId":"32651","inReplyTo":"201301181833.r0IIXNGb027544@smtpb02.one-mail.on.ca","subject":"RE: Question re. git remote repository","fromName":"David Lang","fromEmail":"david@lang.hm","sentAt":"2013-01-18T20:27:51Z","receivedAt":"2013-01-18T20:27:51Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"What I would do is to have each developer have their own local copy that they \nare working on.\n\nI would then find a machine that is going to be on all the time (which could be \na developer's desktop), and create a master repository there. Note that if this \nis on a developers desktop, this needs to be a different repository (or at the \nvery least a different branch) from what they use to do their work.\n\ndevelopers then do their work locally, and after a change has been reviewed, \npull it into the master repository.\n\n\nThis can even be done if you only have one developer (although then you may just \nuse branches instead of a separate repository)\n\nThe idea is that when you start working on a new feature, you create a new \nbranch from the master, implement your new feature, and then (after testing) \nmerge the completed feature into the master branch/repository.\n\nIf developers are working on multiple things at once, they should have multiple \nbranches. This is a hard habit to get into.\n\nThe tendancy is that while you are in changing code, you see something unrelated \nthat needs fixing, so you fix it and go back to what you were doing.\n\nYou should try to get into the habit of not fixing unrelated things in one \nbranch (or having a separate branch you use only for trivial fixes)\n\nThe idea is that each feature branch should have one set of related changes in \nit, so that you can merge in a branch when it's ready and not end up with one \nfix being tied in to another one,\n\nDavid Lang\n\n\n\nOn Fri, 18 Jan 2013, Lang, David wrote:\n\n> Hi Matt and David,\n>\n> Your responses have been very helpful for this newbie...thanks very much! I have a good sense now of the difference btw a CVCS and a DVCS. Here are two more questions...\n>\n> 1. I now get the sense that there's quite a few options in regards to the way that any one group implements their \"origin\"/\"master\"/<fill in your favourite name> repository. But ultimately, there shouldn't be a question of \"if\" you have a master repository but \"where\" you have the master repository, correct? Or in other words, it doesn't seem like you'd want to designate any one developer's local repository as also being the master repository, right? My sense is that would defeat the purpose of the DVCS.\n>\n> 2. Assuming I'm right about question #1, our first hurdle is where to host the master repository. Could you provide any suggestions for a setup based on our VERY simple department model? I work for a small IT department with a grand total of TWO developers (who sit five feet apart from one another)! The reason we're looking at a VCS is because I was hired a few months ago and the dept never needed one before now. We realize that git will be overkill for what we need but frankly anything will be overkill for what we need, and since git seems to be so well regarded in the community (and free) it looks like a good choice.\n>\n> So the question is, how would either of you recommend we set up our master repository? We definitely want to keep everything \"in house\" so off-site hosting isn't something we'd consider. We have access to many servers on our company's network, some of which we have full rights to, so there's no issue in regards to storage space. I suppose another idea would be to have the master simply reside on one of the two developers local machines, so one of us would have both a local rep and the master rep and the other of us would have just a local rep. This would simplify the model. What do you think? Or is it best to always have the master hosted on a machine with no other local reps?\n>\n> David\n"},{"id":"207225","messageId":"7v622uqjch.fsf@alter.siamese.dyndns.org","threadId":"32651","inReplyTo":"alpine.DEB.2.02.1301181127590.21503@nftneq.ynat.uz","subject":"Re: Question re. git remote repository","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-18T21:20:14Z","receivedAt":"2013-01-18T21:20:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Lang <david@lang.hm> writes:\n\n> What I would do is to have each developer have their own local copy\n> that they are working on.\n>\n> I would then find a machine that is going to be on all the time (which\n> could be a developer's desktop), and create a master repository\n> there. Note that if this is on a developers desktop, this needs to be\n> a different repository ... from\n> what they use to do their work.\n>\n> developers then do their work locally, and after a change has been\n> reviewed, pull it into the master repository.\n\ns/pull it into/push it into/; I think.\n"},{"id":"207226","messageId":"alpine.DEB.2.02.1301181320070.21503@nftneq.ynat.uz","threadId":"32651","inReplyTo":"7v622uqjch.fsf@alter.siamese.dyndns.org","subject":"Re: Question re. git remote repository","fromName":"David Lang","fromEmail":"david@lang.hm","sentAt":"2013-01-18T21:27:55Z","receivedAt":"2013-01-18T21:27:55Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Fri, 18 Jan 2013, Junio C Hamano wrote:\n\n> David Lang <david@lang.hm> writes:\n>\n>> What I would do is to have each developer have their own local copy\n>> that they are working on.\n>>\n>> I would then find a machine that is going to be on all the time (which\n>> could be a developer's desktop), and create a master repository\n>> there. Note that if this is on a developers desktop, this needs to be\n>> a different repository ... from\n>> what they use to do their work.\n>>\n>> developers then do their work locally, and after a change has been\n>> reviewed, pull it into the master repository.\n>\n> s/pull it into/push it into/; I think.\n\nfair enough, I always think in terms of pulling from feature branches into the \nmain repository so that any merge conflicts get resolved. I didn't describe this \nclearly enough.\n\nJunio, is there a really good place we should be pointing David where the \ndifferent workflows are described and explained?\n\nfor David\n\nAfter the work is completed in the feature branches, you now have the problem of \nhow to combine this work in with whatever other work has taken place in the \nmeantime.\n\nOne common way to do this is to pull from the feature branch into the main tree. \nIf there are conflicts, git will help you identify them and resolve them (note \nthat some changes will not produce conflicts that git detects, but can still \nresult in non-working code)\n\ndevelopers can (and should) do a dry run on this if significant changes have \nhappened in the master. Create a new throw-away branch of the master tree and \nmerge your feature branch into that tree and see what happens. If everything \nworks, you are good to go. If you have massive conflicts, it may be worth doing \nwork to avoid the conflicts and then submit the result of that to the master \n(also known as upstream)\n\nWith only two developers, you can have each of them do the merge work on a \ntemporary branch and then push the results upstream to the master, or you can \nhave one of them 'change hats' to be the release manager and work from the point \nof view of the master to pull the changes in)\n\nDavid Lang\n"},{"id":"207227","messageId":"7v1udiqiic.fsf@alter.siamese.dyndns.org","threadId":"32651","inReplyTo":"alpine.DEB.2.02.1301181320070.21503@nftneq.ynat.uz","subject":"Re: Question re. git remote repository","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-18T21:38:19Z","receivedAt":"2013-01-18T21:38:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Lang <david@lang.hm> writes:\n\n> On Fri, 18 Jan 2013, Junio C Hamano wrote:\n>\n>> David Lang <david@lang.hm> writes:\n>> ...\n>>> developers then do their work locally, and after a change has been\n>>> reviewed, pull it into the master repository.\n>>\n>> s/pull it into/push it into/; I think.\n>\n> fair enough, I always think in terms of pulling from feature branches\n> into the main repository so that any merge conflicts get resolved. I\n> didn't describe this clearly enough.\n\nIf you are assuming that the \"main repository\" has a working tree\nand somebody goes there, runs \"git pull\" and manually resolves\nconflicts, that may be asking for trouble down the road. It may be\nsufficient for two-person group as long as they coordinate among\nthemselves so that only one of them uses that working tree at the\n\"main repository\" at a time.\n\nBut in general, it is more common to have a bare repository without\nany working tree as the \"main repository\", let a push that conflicts\nfail, and have the pusher fetch from the \"main repository\" and fix\nup the conflicts in his working repository before he tries to push\nthe cleaned-up result.  That gives the pusher a chance to re-test\nthe result of integration with what he did not see while he was\ndeveloping what he attempted to push.\n\n\"pull\" and \"pull -rebase\" are two ways to do that \"fetch from the\n'main' and fix up\" step.\n"},{"id":"207228","messageId":"1BBEF94B6B46E54980290D150A6F2EDD46B7D7D0@BN1PRD0612MB635.namprd06.prod.outlook.com","threadId":"32651","inReplyTo":"201301181833.r0IIXNe7021768@smtpb01.one-mail.on.ca","subject":"RE: Question re. git remote repository","fromName":"Matt Seitz","fromEmail":"mseitz@mhseitz.onmicrosoft.com","sentAt":"2013-01-18T21:56:31Z","receivedAt":"2013-01-18T21:56:31Z","isPatch":false,"sender":{"key":"mseitz@mhseitz.onmicrosoft.com","avatar":null},"body":"\n\n> -----Original Message-----\n> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On\n> \n> But ultimately, there shouldn't be a question of \"if\" you\n> have a master repository but \"where\" you have the master repository, correct?\n> Or in other words, it doesn't seem like you'd want to designate any one\n> developer's local repository as also being the master repository, right? \n\nYou have two options:\n\n1.  Central model:  \na. each developer has their own private repository\nb. each developer uses \"git commit\" to commit changes into their own private repository\nc. in addition, you also have a shared master repository\nd. each developer uses \"git push\" to push their changes from their private repository to the shared master repository\ne. each developer uses \"git pull\" to pull other developers' changes from the shared master repository\n\n2.  Peer-to-peer model:\na. each developer has their own private repository\nb. each developer uses \"git commit\" to commit changes into their own private repository\nc. each developer uses \"git pull\" to pull other developers' changes from other developers' private repositories\n\nYou can even mix these models.  Say you have a 5 member team, and 2 members are working on a feature together.  The 2 people working on the feature may use \"git pull\" to pull changes from each other's private repositories.  Then, when the feature is ready, one of them can use \"git push\" to push the final version from their private repository into the team's shared repository.\n\nWhat you don't want to do is this:\n\nSingle repository, multiple developers:  just one repository, and every developer uses \"git commit\" to commit their changes into the same repository.\n\n> My sense is that would defeat the purpose of the DVCS.\n\nNot at all.  The purpose of the DVCS is to allow each developer to have their own private repository where they can commit changes, while still allowing people to share changes from one repository to another.  That's true whether you use the central model or the peer-to-peer model.  \n\nThe traditional VCS has just one repository, and everyone has to commit their changes into that one central repository.\n\n> We have access to many servers on our\n> company's network, some of which we have full rights to, so there's no issue in\n> regards to storage space.\n\nThat will work fine.\n\n> I suppose another idea would be to have the master\n> simply reside on one of the two developers local machines, so one of us would\n> have both a local rep and the master rep and the other of us would have just a\n> local rep. \n\nThat will also work.  You could even omit the master rep. and just have each developer have a local repository.  Each developer could then commit changes to their own local repository, and pull the other developer's changes from the other developer's local repository (the peer-to-peer model mentioned above).\n\n> Or is it best to\n> always have the master hosted on a machine with no other local reps?\n\nThere's no requirement to have the master hosted on a machine with no other local reps.  The only issue is that the machine with the master rep. must be turned on for the other developers to push changes from their private repositories to the master repository.  Having the master repository on a 24x7 server ensures it is always available to all developers.  It also gives you another backup copy of your code, in case the developer's machine's storage fails or gets corrupted.\n"},{"id":"207235","messageId":"2F1BADBEC6D84C95AE8AE6BB898D3E03@PhilipOakley","threadId":"32651","inReplyTo":"alpine.DEB.2.02.1301181320070.21503@nftneq.ynat.uz","subject":"Re: Question re. git remote repository","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2013-01-18T23:05:57Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"David Lang\" <david@lang.hm>\nSent: Friday, January 18, 2013 9:27 PM\n> On Fri, 18 Jan 2013, Junio C Hamano wrote:\n>\n>> David Lang <david@lang.hm> writes:\n>>\n>>> What I would do is to have each developer have their own local copy\n>>> that they are working on.\n>>>\n\nIf you have a third machine to host the bare 'master' repo that would \nprovide additional security/backup to touy local machines.\n\n[...]\n>\n> Junio, is there a really good place we should be pointing David where \n> the different workflows are described and explained?\n\n`git help workflows` perhaps.\n\nPhilip \n"},{"id":"207622","messageId":"201301231941.r0NJf3oa001238@smtpb01.one-mail.on.ca","threadId":"32651","inReplyTo":"1BBEF94B6B46E54980290D150A6F2EDD46B7D7D0@BN1PRD0612MB635.namprd06.prod.outlook.com","subject":"RE: Question re. git remote repository","fromName":"Lang, David","fromEmail":"david.lang@uhn.ca","sentAt":"2013-01-23T19:40:50Z","receivedAt":"2013-01-23T19:40:50Z","isPatch":false,"sender":{"key":"david.lang@uhn.ca","avatar":null},"body":"Thanks Matt and Dave and everyone else for your feedback on this.\n\nOk, I've done some more reading in the Pro Git manual and I think I have an idea of how to get started. Could I run this by you just in case I'm missing anything? Currently (pre-git status) what we have is two developers both working in Visual Studio, occasionally on the same project (hence the need for git). All the VS projects exist on a server and are accessible to both developers via a network share. Currently, if one of us needs to work on a project we turn around and ask our colleague if he's currently in it...this is how we avoid both being in at the same time. We run VS locally on each of our PC's and load the VS project into Visual Studio from the network share. Easy enough...\n\nSo to get this all set up with git, here's what I think I have to do...\n\n1. Download and install git for Windows on the 2 networked developer's PC's and the 1 networked server.\n\n2. On the server...\n\ta) Initialize the Visual Studio folder for a particular project as a git repository using 'git init'\n\tb) Using the git rep just created (above), create a bare repository on the server to act as the remote/master repository using 'git clone --bare'\n\n3. On each of the PC's...\n\ta) Clone the remote repository from the network server using 'git clone' (this will automatically create 'origin' as a remote source on the PC's)\n\nCouple of questions...\n\n1. Anyone see any problems/issues with the above?\n\n2. Is it sufficient to use the local protocol for transferring files? Seems like the most straightforward.\n\n3. On p.84 of the guide there's a section entitled \"Putting the Bare Repository on a Server\" but since the first two rep's (original and bare) are already on the server, this is unnecessary, correct?\n\n4. The original Visual Studio project folder essentially remains untouched, correct? The 'git init' and 'git clone' commands just make copies and references of whatever data is in the VS project folder, right?\n\nDavid\n\n> -----Original Message-----\n> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On\n> \n> But ultimately, there shouldn't be a question of \"if\" you have a \n> master repository but \"where\" you have the master repository, correct?\n> Or in other words, it doesn't seem like you'd want to designate any \n> one developer's local repository as also being the master repository, right?\n\nYou have two options:\n\n1.  Central model:  \na. each developer has their own private repository b. each developer uses \"git commit\" to commit changes into their own private repository c. in addition, you also have a shared master repository d. each developer uses \"git push\" to push their changes from their private repository to the shared master repository e. each developer uses \"git pull\" to pull other developers' changes from the shared master repository\n\n2.  Peer-to-peer model:\na. each developer has their own private repository b. each developer uses \"git commit\" to commit changes into their own private repository c. each developer uses \"git pull\" to pull other developers' changes from other developers' private repositories\n\nYou can even mix these models.  Say you have a 5 member team, and 2 members are working on a feature together.  The 2 people working on the feature may use \"git pull\" to pull changes from each other's private repositories.  Then, when the feature is ready, one of them can use \"git push\" to push the final version from their private repository into the team's shared repository.\n\nWhat you don't want to do is this:\n\nSingle repository, multiple developers:  just one repository, and every developer uses \"git commit\" to commit their changes into the same repository.\n\n> My sense is that would defeat the purpose of the DVCS.\n\nNot at all.  The purpose of the DVCS is to allow each developer to have their own private repository where they can commit changes, while still allowing people to share changes from one repository to another.  That's true whether you use the central model or the peer-to-peer model.  \n\nThe traditional VCS has just one repository, and everyone has to commit their changes into that one central repository.\n\n> We have access to many servers on our\n> company's network, some of which we have full rights to, so there's no \n> issue in regards to storage space.\n\nThat will work fine.\n\n> I suppose another idea would be to have the master simply reside on \n> one of the two developers local machines, so one of us would have both \n> a local rep and the master rep and the other of us would have just a \n> local rep.\n\nThat will also work.  You could even omit the master rep. and just have each developer have a local repository.  Each developer could then commit changes to their own local repository, and pull the other developer's changes from the other developer's local repository (the peer-to-peer model mentioned above).\n\n> Or is it best to\n> always have the master hosted on a machine with no other local reps?\n\nThere's no requirement to have the master hosted on a machine with no other local reps.  The only issue is that the machine with the master rep. must be turned on for the other developers to push changes from their private repositories to the master repository.  Having the master repository on a 24x7 server ensures it is always available to all developers.  It also gives you another backup copy of your code, in case the developer's machine's storage fails or gets corrupted.\n\n\n\n\nThis e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. \nAny review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. \nIf you have received this e-mail in error, please contact the sender and delete all copies. \nOpinions, conclusions or other information contained in this e-mail may not be that of the organization.\n"},{"id":"207631","messageId":"7va9rzhcl0.fsf@alter.siamese.dyndns.org","threadId":"32651","inReplyTo":"201301231941.r0NJf3oa001238@smtpb01.one-mail.on.ca","subject":"Re: Question re. git remote repository","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-23T20:24:43Z","receivedAt":"2013-01-23T20:24:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Lang, David\" <David.Lang@uhn.ca> writes:\n\n> Thanks Matt and Dave and everyone else for your feedback on this.\n\n[administrivia: please wrap your lines to reasonable length]\n\n> 1. Download and install git for Windows on the 2 networked developer's\n> PC's and the 1 networked server.\n>\n> 2. On the server...\n> \tA) Initialize the Visual Studio folder for a particular\n> project as a git repository using 'git init'\n> \tb) Using the git rep just created (above), create a bare\n> repository on the server to act as the remote/master repository using\n> git clone --bare'\n\noptionally:\n\n\tC) remove the original directory (A)\n\n        D) make a non-bare clone on the server with \"git clone\", if\n    \t   you would like to have a single build environment on the\n    \t   server box.\n\n        E) Use \"git pull\" from the bare repository you created in\n    \t   step (2.B) to update the repository you created in step\n    \t   (2.D) as necessary in order to build the latest in this\n    \t   repository.\n\n> 3. On each of the PC's...\n> \tA) Clone the remote repository from the network server using\n> git clone' (this will automatically create 'origin' as a remote source\n> on the PC's)\n\n\tB) Each developer works in his repository; use either \"git\n           pull\" or \"git pull --rebase\" to sync up with the tip of\n           the master repository as necessary;\n\n\tC) When a developer's work reaches a point where it is good\n           enough to update the master repository, use \"git push\" to\n           update the bare repository you created on the server in\n           step (2.B).  This may need to trigger step (2.E).\n\n> Couple of questions...\n> ...\n> 4. The original Visual Studio project folder essentially remains\n> untouched, correct? The 'git init' and 'git clone' commands just make\n> copies and references of whatever data is in the VS project folder,\n> right?\n\nThese operations make copies and after making copies they do not\never refer to the original, so you can take a back-up of the\noriginal and remove it (i.e. optional step (c)).\n"}]}