# Question re. git remote repository 21 messages from 2013-01-16 to 2013-01-23. Participants: Lang, David, Konstantin Khomoutov, Jeff King, David Lang, Stephen Smith, Matt Seitz, Junio C Hamano, Philip Oakley. Thread: https://gitlist.dev/t/32651 ## Lang, David, 2013-01-16 17:49 Subject: Question re. git remote repository Message-ID: <201301161749.r0GHnGV6007806@smtpb02.one-mail.on.ca> URL: https://gitlist.dev/e/201301161749.r0GHnGV6007806%40smtpb02.one-mail.on.ca ``` Hello, We'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. It 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? Thanks in advance for the help. David Lang | Application Developer | Tel: 416-340-4800 x.5277 Cardiac IT Dept - Toronto General Hospital The University Health Network 200 Elizabeth St. Toronto, ON   M5G 2C4 This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this e-mail may not be that of the organization. ``` ## Konstantin Khomoutov, 2013-01-16 18:06 Subject: Re: Question re. git remote repository Message-ID: <20130116220615.48c159546bccfa5b9cd9028e@domain007.com> URL: https://gitlist.dev/e/20130116220615.48c159546bccfa5b9cd9028e%40domain007.com In-Reply-To: <201301161749.r0GHnGV6007806@smtpb02.one-mail.on.ca> ``` On Wed, 16 Jan 2013 17:49:09 +0000 "Lang, David" wrote: > We'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. The name "origin" is purely arbitrary: any local repository might have > It appears from the limited reading I've done that the remote > repository must be hosted at github.com. Is this the case? Of course not. github is just a Git hosting provider. There are plenty of them -- both commercial and not-for-profit (a well-known service bitbucket.org is one example). > Ideally we'd prefer to simply create our remote repository on a drive > of one of our local network servers. Is this possible? Yes, this is possible, but it's not advised to keep such a "reference" repository on an exported networked drive for a number of reasons (both performance and bug-free operation). Instead, the canonical way to host "reference" repositories is to make them accessible via SSH or via HTTP[S]. To do this, a server running some POSIX OS (Linux- or *BSD-based) is the best bet. Both kinds of access require Git itself installed on the server. Obviously, SSH access requires an SSH server software (such as OpenSSH) as well and HTTP[S] access requires a web server (such as Apache). Of course, everything mentioned is available on any sensible OS you might install on your server. Read-only access might be provided by a special tool named "Git daemon" which is a part of Git. If you have more than a couple of developers you might want to install certain front-end Git software on the server which provides for "virtualized" Git users and fine-grained control over who can do what. Using gitolite [3] for this is the current trend. Web-browsing for your repositories, if needed, is usually provided by the tool named gitweb [4]. Everything I've just summarised is well explained in [5] and [6] (as an addendum). Another approach is to set up a "turn-key" solution such as GitLab [1] or gitblit [2]. 1. http://gitlabhq.com/ 2. http://gitblit.com/ 3. https://github.com/sitaramc/gitolite 4. https://git.wiki.kernel.org/index.php/Gitweb 5. http://git-scm.com/book/en/Git-on-the-Server 6. http://git-scm.com/2010/03/04/smart-http.html ``` ## Jeff King, 2013-01-16 18:21 Subject: Re: Question re. git remote repository Message-ID: <20130116182156.GB4426@sigill.intra.peff.net> URL: https://gitlist.dev/e/20130116182156.GB4426%40sigill.intra.peff.net In-Reply-To: <20130116220615.48c159546bccfa5b9cd9028e@domain007.com> ``` On Wed, Jan 16, 2013 at 10:06:15PM +0400, Konstantin Khomoutov wrote: > > 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. Note that this is just one common topology for setting up repos (and it is probably the simplest). Others are described here: http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows > > Ideally we'd prefer to simply create our remote repository on a drive > > of one of our local network servers. Is this possible? > > Yes, this is possible, but it's not advised to keep such a "reference" > repository on an exported networked drive for a number of reasons (both > performance and bug-free operation). I agree that performance is not ideal (although if you are on a fast LAN, it probably would not matter much), but I do not recall any specific bugs in that area. Can you elaborate? -Peff ``` ## Konstantin Khomoutov, 2013-01-16 19:37 Subject: Re: Question re. git remote repository Message-ID: <20130116233744.7d0775eaec98ce154a9de180@domain007.com> URL: https://gitlist.dev/e/20130116233744.7d0775eaec98ce154a9de180%40domain007.com In-Reply-To: <20130116182156.GB4426@sigill.intra.peff.net> ``` On Wed, 16 Jan 2013 10:21:56 -0800 Jeff King wrote: Thanks for elaborating on the "origin" -- I intended to write up on its special status but got distracted and sent my message missing that bit ;-) [...] > > > Ideally we'd prefer to simply create our remote repository on a > > > drive of one of our local network servers. Is this possible? > > > > Yes, this is possible, but it's not advised to keep such a > > "reference" repository on an exported networked drive for a number > > of reasons (both performance and bug-free operation). > > I agree that performance is not ideal (although if you are on a fast > LAN, it probably would not matter much), but I do not recall any > specific bugs in that area. Can you elaborate? This one [1] for instance. I also recall seing people having other "mystical" problems with setups like this so I somehow developed an idea than having a repository on a networked drive is asking for troubles. Of course, if there are happy users of such setups, I would be glad to hear as my precautions might well be unfounded for the recent versions of Git. 1. http://code.google.com/p/msysgit/issues/detail?id=130 ``` ## David Lang, 2013-01-16 20:07 Subject: Re: Question re. git remote repository Message-ID: URL: https://gitlist.dev/e/alpine.DEB.2.02.1301161202390.21503%40nftneq.ynat.uz In-Reply-To: <201301161749.r0GHnGV6007806@smtpb02.one-mail.on.ca> ``` Hi David, now we are going to have some confusion here, two David Langs on the list :-) On Wed, 16 Jan 2013, Lang, David wrote: > We'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. > > It 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? Git is peer-to-peer, the 'origin' is just the default to pull from. It can be hosted on any machine that you have access to. A typical case is that you designate one person (or a small group of people) to oversee your master repository, and that person decides when and what to pull there from the developers. This gives you a chance to insert code review, tests, etc between what the developers produce in their local repository and what you then bless as the authoritative 'released' version of the code. However, this master repository is just a matter of convention, it is possible to use any repository as the 'origin', changing it is just a config change away. David Lang ``` ## Stephen Smith, 2013-01-16 22:59 Subject: Re: Question re. git remote repository Message-ID: <0630A778-9AC8-4023-889C-4FC58ABAB683@gmail.com> URL: https://gitlist.dev/e/0630A778-9AC8-4023-889C-4FC58ABAB683%40gmail.com In-Reply-To: <20130116233744.7d0775eaec98ce154a9de180@domain007.com> ``` >>>> Ideally we'd prefer to simply create our remote repository on a >>>> drive of one of our local network servers. Is this possible? >>> >>> Yes, this is possible, but it's not advised to keep such a >>> "reference" repository on an exported networked drive for a number >>> of reasons (both performance and bug-free operation). >> >> I agree that performance is not ideal (although if you are on a fast >> LAN, it probably would not matter much), but I do not recall any >> specific bugs in that area. Can you elaborate? > > This one [1] for instance. I also recall seing people having other > "mystical" problems with setups like this so I somehow developed an idea > than having a repository on a networked drive is asking for troubles. > Of course, if there are happy users of such setups, I would be glad to > hear as my precautions might well be unfounded for the recent versions > of Git. > > 1. http://code.google.com/p/msysgit/issues/detail?id=130 A group I was with used a master repository on a windows share for quite some time without a database corruption being seen. ``` ## David Lang, 2013-01-16 23:00 Subject: Re: Question re. git remote repository Message-ID: URL: https://gitlist.dev/e/alpine.DEB.2.02.1301161459060.21503%40nftneq.ynat.uz In-Reply-To: <0630A778-9AC8-4023-889C-4FC58ABAB683@gmail.com> ``` On Wed, 16 Jan 2013, Stephen Smith wrote: >>>>> Ideally we'd prefer to simply create our remote repository on a >>>>> drive of one of our local network servers. Is this possible? >>>> >>>> Yes, this is possible, but it's not advised to keep such a >>>> "reference" repository on an exported networked drive for a number >>>> of reasons (both performance and bug-free operation). >>> >>> I agree that performance is not ideal (although if you are on a fast >>> LAN, it probably would not matter much), but I do not recall any >>> specific bugs in that area. Can you elaborate? >> >> This one [1] for instance. I also recall seing people having other >> "mystical" problems with setups like this so I somehow developed an idea >> than having a repository on a networked drive is asking for troubles. >> Of course, if there are happy users of such setups, I would be glad to >> hear as my precautions might well be unfounded for the recent versions >> of Git. >> >> 1. http://code.google.com/p/msysgit/issues/detail?id=130 > > A group I was with used a master repository on a windows share for quite some time without a database corruption being seen. -- I think the risk is that if you have multiple people doing actions on the shared filesystem you can run into trouble. 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. 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. David Lang ``` ## Lang, David, 2013-01-17 21:53 Subject: RE: Question re. git remote repository Message-ID: <201301172153.r0HLrU4F019815@smtpb02.one-mail.on.ca> URL: https://gitlist.dev/e/201301172153.r0HLrU4F019815%40smtpb02.one-mail.on.ca In-Reply-To: ``` Hi David, Ok, 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." Isn'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). What am I missing? The 'other' David Lang ;-) -----Original Message----- From: David Lang [mailto:david@lang.hm] Sent: Wednesday, January 16, 2013 6:01 PM To: Stephen Smith Cc: Konstantin Khomoutov; Jeff King; git@vger.kernel.org; Lang, David Subject: Re: Question re. git remote repository On Wed, 16 Jan 2013, Stephen Smith wrote: >>>>> Ideally we'd prefer to simply create our remote repository on a >>>>> drive of one of our local network servers. Is this possible? >>>> >>>> Yes, this is possible, but it's not advised to keep such a >>>> "reference" repository on an exported networked drive for a number >>>> of reasons (both performance and bug-free operation). >>> >>> I agree that performance is not ideal (although if you are on a fast >>> LAN, it probably would not matter much), but I do not recall any >>> specific bugs in that area. Can you elaborate? >> >> This one [1] for instance. I also recall seing people having other >> "mystical" problems with setups like this so I somehow developed an >> idea than having a repository on a networked drive is asking for troubles. >> Of course, if there are happy users of such setups, I would be glad >> to hear as my precautions might well be unfounded for the recent >> versions of Git. >> >> 1. http://code.google.com/p/msysgit/issues/detail?id=130 > > A group I was with used a master repository on a windows share for quite some time without a database corruption being seen. -- I think the risk is that if you have multiple people doing actions on the shared filesystem you can run into trouble. 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. 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. David Lang This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this e-mail may not be that of the organization. ``` ## David Lang, 2013-01-17 23:19 Subject: RE: Question re. git remote repository Message-ID: URL: https://gitlist.dev/e/alpine.DEB.2.02.1301171514530.21503%40nftneq.ynat.uz In-Reply-To: <201301172153.r0HLrUIr001039@smtpb01.one-mail.on.ca> ``` distributed version control systems let each developer have a full repository locally on their machine, they then can send updates to other people who have a repository (or a pull request which asks the other person to pull from the developers repository to the other persons repository) Most projects have one repository that they designate as being the 'main' repository for the project, and developers push updates to it (or send pull requests to the people who own that repository) The communication between developers is typically via e-mail and the repository updates are sent via the git-daemon and the git network protocol. This sort of thing is very different from the model where there is one repository on a shared disk somewhere and everyone accesses that shared disk to do their work or apply updates via NFS/CIFS protocols. Does this clarify the difference? David Lang On Thu, 17 Jan 2013, Lang, David wrote: > Hi David, > > Ok, 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." > > Isn'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). > > What am I missing? > > The 'other' David Lang ;-) > > -----Original Message----- > From: David Lang [mailto:david@lang.hm] > Sent: Wednesday, January 16, 2013 6:01 PM > To: Stephen Smith > Cc: Konstantin Khomoutov; Jeff King; git@vger.kernel.org; Lang, David > Subject: Re: Question re. git remote repository > > On Wed, 16 Jan 2013, Stephen Smith wrote: > >>>>>> Ideally we'd prefer to simply create our remote repository on a >>>>>> drive of one of our local network servers. Is this possible? >>>>> >>>>> Yes, this is possible, but it's not advised to keep such a >>>>> "reference" repository on an exported networked drive for a number >>>>> of reasons (both performance and bug-free operation). >>>> >>>> I agree that performance is not ideal (although if you are on a fast >>>> LAN, it probably would not matter much), but I do not recall any >>>> specific bugs in that area. Can you elaborate? >>> >>> This one [1] for instance. I also recall seing people having other >>> "mystical" problems with setups like this so I somehow developed an >>> idea than having a repository on a networked drive is asking for troubles. >>> Of course, if there are happy users of such setups, I would be glad >>> to hear as my precautions might well be unfounded for the recent >>> versions of Git. >>> >>> 1. http://code.google.com/p/msysgit/issues/detail?id=130 >> >> A group I was with used a master repository on a windows share for quite some time without a database corruption being seen. -- > > I think the risk is that if you have multiple people doing actions on the shared filesystem you can run into trouble. > > 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. > > 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. > > David Lang > > This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. > Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. > If you have received this e-mail in error, please contact the sender and delete all copies. > Opinions, conclusions or other information contained in this e-mail may not be that of the organization. > > ``` ## Jeff King, 2013-01-17 23:49 Subject: Re: Question re. git remote repository Message-ID: <20130117234912.GA14936@sigill.intra.peff.net> URL: https://gitlist.dev/e/20130117234912.GA14936%40sigill.intra.peff.net In-Reply-To: ``` On Wed, Jan 16, 2013 at 03:00:41PM -0800, David Lang wrote: > >>This one [1] for instance. I also recall seing people having other > >>"mystical" problems with setups like this so I somehow developed an idea > >>than having a repository on a networked drive is asking for troubles. > >>Of course, if there are happy users of such setups, I would be glad to > >>hear as my precautions might well be unfounded for the recent versions > >>of Git. > >> > >>1. http://code.google.com/p/msysgit/issues/detail?id=130 > > > >A group I was with used a master repository on a windows share for quite some time without a database corruption being seen. -- > > I think the risk is that if you have multiple people doing actions on > the shared filesystem you can run into trouble. > > 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. That should not be an issue. Git on a server has to deal with multiple independent receive-pack's running to accept several simultaneous pushes. They coordinate through the use of file locks. Having multiple machines pushing over a shared filesystem should work the same, as long as the filesystem support atomic creation of files with O_EXCL. There may be other subtle issues lurking (e.g., the Windows issue that Konstantin mentioned), but as far as I know, it _should_ work in general. -Peff ``` ## Matt Seitz, 2013-01-18 05:51 Subject: RE: Question re. git remote repository Message-ID: <1BBEF94B6B46E54980290D150A6F2EDD46B7AAE2@BN1PRD0612MB635.namprd06.prod.outlook.com> URL: https://gitlist.dev/e/1BBEF94B6B46E54980290D150A6F2EDD46B7AAE2%40BN1PRD0612MB635.namprd06.prod.outlook.com In-Reply-To: <201301172153.r0HLrU4F019815@smtpb02.one-mail.on.ca> ``` From: git-owner@vger.kernel.org [git-owner@vger.kernel.org] on behalf of Lang, David [David.Lang@uhn.ca] > I thought the idea was that each developer installed git locally on their machines Yes. > 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 Yes, but committing their changes to the master repository is a two step process: 1. Each developer first commits their changes to their personal repository using the "git commit" command. 2. Each developer pushes their changes from their personal repository to the master repository with the "git push" command > (and which I'm assuming has git installed locally as well). Maybe. If 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. If 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". 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: http://permalink.gmane.org/gmane.comp.version-control.git/122670 The GitFaq wiki also says that using "git push" over NFS or CIFS/SMB is safe and reliable: https://git.wiki.kernel.org/index.php/GitFaq#What_can_I_use_to_set_up_a_public_repository.3F ``` ## David Lang, 2013-01-18 06:18 Subject: RE: Question re. git remote repository Message-ID: URL: https://gitlist.dev/e/alpine.DEB.2.02.1301172216310.2151%40nftneq.ynat.uz In-Reply-To: <1BBEF94B6B46E54980290D150A6F2EDD46B7AAE2@BN1PRD0612MB635.namprd06.prod.outlook.com> ``` On Fri, 18 Jan 2013, Matt Seitz wrote: > From: git-owner@vger.kernel.org [git-owner@vger.kernel.org] on behalf of Lang, David [David.Lang@uhn.ca] > > 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: > > http://permalink.gmane.org/gmane.comp.version-control.git/122670 > > The GitFaq wiki also says that using "git push" over NFS or CIFS/SMB is safe and reliable: > > https://git.wiki.kernel.org/index.php/GitFaq#What_can_I_use_to_set_up_a_public_repository.3F I'm glad to learn that git is more robust than I feared. David Lang ``` ## Lang, David, 2013-01-18 18:33 Subject: RE: Question re. git remote repository Message-ID: <201301181833.r0IIXNe7021768@smtpb01.one-mail.on.ca> URL: https://gitlist.dev/e/201301181833.r0IIXNe7021768%40smtpb01.one-mail.on.ca In-Reply-To: <1BBEF94B6B46E54980290D150A6F2EDD46B7AAE2@BN1PRD0612MB635.namprd06.prod.outlook.com> ``` Hi Matt and David, 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... 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"/ 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. 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. 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? David -----Original Message----- From: Matt Seitz [mailto:mseitz@mhseitz.onmicrosoft.com] Sent: Friday, January 18, 2013 12:52 AM To: Lang, David; David Lang Cc: Konstantin Khomoutov; Jeff King; git@vger.kernel.org; Stephen Smith Subject: RE: Question re. git remote repository From: git-owner@vger.kernel.org [git-owner@vger.kernel.org] on behalf of Lang, David [David.Lang@uhn.ca] > I thought the idea was that each developer installed git locally on > their machines Yes. > 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 Yes, but committing their changes to the master repository is a two step process: 1. Each developer first commits their changes to their personal repository using the "git commit" command. 2. Each developer pushes their changes from their personal repository to the master repository with the "git push" command > (and which I'm assuming has git installed locally as well). Maybe. If 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. If 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". 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: http://permalink.gmane.org/gmane.comp.version-control.git/122670 The GitFaq wiki also says that using "git push" over NFS or CIFS/SMB is safe and reliable: https://git.wiki.kernel.org/index.php/GitFaq#What_can_I_use_to_set_up_a_public_repository.3F This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this e-mail may not be that of the organization. ``` ## David Lang, 2013-01-18 20:27 Subject: RE: Question re. git remote repository Message-ID: URL: https://gitlist.dev/e/alpine.DEB.2.02.1301181127590.21503%40nftneq.ynat.uz In-Reply-To: <201301181833.r0IIXNGb027544@smtpb02.one-mail.on.ca> ``` What I would do is to have each developer have their own local copy that they are working on. I would then find a machine that is going to be on all the time (which could be a developer's desktop), and create a master repository there. Note that if this is on a developers desktop, this needs to be a different repository (or at the very least a different branch) from what they use to do their work. developers then do their work locally, and after a change has been reviewed, pull it into the master repository. This can even be done if you only have one developer (although then you may just use branches instead of a separate repository) The idea is that when you start working on a new feature, you create a new branch from the master, implement your new feature, and then (after testing) merge the completed feature into the master branch/repository. If developers are working on multiple things at once, they should have multiple branches. This is a hard habit to get into. The tendancy is that while you are in changing code, you see something unrelated that needs fixing, so you fix it and go back to what you were doing. You should try to get into the habit of not fixing unrelated things in one branch (or having a separate branch you use only for trivial fixes) The idea is that each feature branch should have one set of related changes in it, so that you can merge in a branch when it's ready and not end up with one fix being tied in to another one, David Lang On Fri, 18 Jan 2013, Lang, David wrote: > Hi Matt and David, > > 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... > > 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"/ 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. > > 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. > > 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? > > David ``` ## Junio C Hamano, 2013-01-18 21:20 Subject: Re: Question re. git remote repository Message-ID: <7v622uqjch.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7v622uqjch.fsf%40alter.siamese.dyndns.org In-Reply-To: ``` David Lang writes: > What I would do is to have each developer have their own local copy > that they are working on. > > I would then find a machine that is going to be on all the time (which > could be a developer's desktop), and create a master repository > there. Note that if this is on a developers desktop, this needs to be > a different repository ... from > what they use to do their work. > > developers then do their work locally, and after a change has been > reviewed, pull it into the master repository. s/pull it into/push it into/; I think. ``` ## David Lang, 2013-01-18 21:27 Subject: Re: Question re. git remote repository Message-ID: URL: https://gitlist.dev/e/alpine.DEB.2.02.1301181320070.21503%40nftneq.ynat.uz In-Reply-To: <7v622uqjch.fsf@alter.siamese.dyndns.org> ``` On Fri, 18 Jan 2013, Junio C Hamano wrote: > David Lang writes: > >> What I would do is to have each developer have their own local copy >> that they are working on. >> >> I would then find a machine that is going to be on all the time (which >> could be a developer's desktop), and create a master repository >> there. Note that if this is on a developers desktop, this needs to be >> a different repository ... from >> what they use to do their work. >> >> developers then do their work locally, and after a change has been >> reviewed, pull it into the master repository. > > s/pull it into/push it into/; I think. fair enough, I always think in terms of pulling from feature branches into the main repository so that any merge conflicts get resolved. I didn't describe this clearly enough. Junio, is there a really good place we should be pointing David where the different workflows are described and explained? for David After the work is completed in the feature branches, you now have the problem of how to combine this work in with whatever other work has taken place in the meantime. One common way to do this is to pull from the feature branch into the main tree. If there are conflicts, git will help you identify them and resolve them (note that some changes will not produce conflicts that git detects, but can still result in non-working code) developers can (and should) do a dry run on this if significant changes have happened in the master. Create a new throw-away branch of the master tree and merge your feature branch into that tree and see what happens. If everything works, you are good to go. If you have massive conflicts, it may be worth doing work to avoid the conflicts and then submit the result of that to the master (also known as upstream) With only two developers, you can have each of them do the merge work on a temporary branch and then push the results upstream to the master, or you can have one of them 'change hats' to be the release manager and work from the point of view of the master to pull the changes in) David Lang ``` ## Junio C Hamano, 2013-01-18 21:38 Subject: Re: Question re. git remote repository Message-ID: <7v1udiqiic.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7v1udiqiic.fsf%40alter.siamese.dyndns.org In-Reply-To: ``` David Lang writes: > On Fri, 18 Jan 2013, Junio C Hamano wrote: > >> David Lang writes: >> ... >>> developers then do their work locally, and after a change has been >>> reviewed, pull it into the master repository. >> >> s/pull it into/push it into/; I think. > > fair enough, I always think in terms of pulling from feature branches > into the main repository so that any merge conflicts get resolved. I > didn't describe this clearly enough. If you are assuming that the "main repository" has a working tree and somebody goes there, runs "git pull" and manually resolves conflicts, that may be asking for trouble down the road. It may be sufficient for two-person group as long as they coordinate among themselves so that only one of them uses that working tree at the "main repository" at a time. But in general, it is more common to have a bare repository without any working tree as the "main repository", let a push that conflicts fail, and have the pusher fetch from the "main repository" and fix up the conflicts in his working repository before he tries to push the cleaned-up result. That gives the pusher a chance to re-test the result of integration with what he did not see while he was developing what he attempted to push. "pull" and "pull -rebase" are two ways to do that "fetch from the 'main' and fix up" step. ``` ## Matt Seitz, 2013-01-18 21:56 Subject: RE: Question re. git remote repository Message-ID: <1BBEF94B6B46E54980290D150A6F2EDD46B7D7D0@BN1PRD0612MB635.namprd06.prod.outlook.com> URL: https://gitlist.dev/e/1BBEF94B6B46E54980290D150A6F2EDD46B7D7D0%40BN1PRD0612MB635.namprd06.prod.outlook.com In-Reply-To: <201301181833.r0IIXNe7021768@smtpb01.one-mail.on.ca> ``` > -----Original Message----- > From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On > > 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? You have two options: 1. Central model: a. 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 2. Peer-to-peer model: a. 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 You 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. What you don't want to do is this: Single repository, multiple developers: just one repository, and every developer uses "git commit" to commit their changes into the same repository. > My sense is that would defeat the purpose of the DVCS. Not 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. The traditional VCS has just one repository, and everyone has to commit their changes into that one central repository. > 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. That will work fine. > 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. That 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). > Or is it best to > always have the master hosted on a machine with no other local reps? There'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. ``` ## Philip Oakley, 2013-01-18 23:05 Subject: Re: Question re. git remote repository Message-ID: <2F1BADBEC6D84C95AE8AE6BB898D3E03@PhilipOakley> URL: https://gitlist.dev/e/2F1BADBEC6D84C95AE8AE6BB898D3E03%40PhilipOakley In-Reply-To: ``` From: "David Lang" Sent: Friday, January 18, 2013 9:27 PM > On Fri, 18 Jan 2013, Junio C Hamano wrote: > >> David Lang writes: >> >>> What I would do is to have each developer have their own local copy >>> that they are working on. >>> If you have a third machine to host the bare 'master' repo that would provide additional security/backup to touy local machines. [...] > > Junio, is there a really good place we should be pointing David where > the different workflows are described and explained? `git help workflows` perhaps. Philip ``` ## Lang, David, 2013-01-23 19:40 Subject: RE: Question re. git remote repository Message-ID: <201301231941.r0NJf3oa001238@smtpb01.one-mail.on.ca> URL: https://gitlist.dev/e/201301231941.r0NJf3oa001238%40smtpb01.one-mail.on.ca In-Reply-To: <1BBEF94B6B46E54980290D150A6F2EDD46B7D7D0@BN1PRD0612MB635.namprd06.prod.outlook.com> ``` Thanks Matt and Dave and everyone else for your feedback on this. Ok, 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... So to get this all set up with git, here's what I think I have to do... 1. Download and install git for Windows on the 2 networked developer's PC's and the 1 networked server. 2. On the server... a) Initialize the Visual Studio folder for a particular project as a git repository using 'git init' b) 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' 3. On each of the PC's... a) Clone the remote repository from the network server using 'git clone' (this will automatically create 'origin' as a remote source on the PC's) Couple of questions... 1. Anyone see any problems/issues with the above? 2. Is it sufficient to use the local protocol for transferring files? Seems like the most straightforward. 3. 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? 4. 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? David > -----Original Message----- > From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On > > 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? You have two options: 1. Central model: a. 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 2. Peer-to-peer model: a. 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 You 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. What you don't want to do is this: Single repository, multiple developers: just one repository, and every developer uses "git commit" to commit their changes into the same repository. > My sense is that would defeat the purpose of the DVCS. Not 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. The traditional VCS has just one repository, and everyone has to commit their changes into that one central repository. > 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. That will work fine. > 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. That 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). > Or is it best to > always have the master hosted on a machine with no other local reps? There'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. This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this e-mail may not be that of the organization. ``` ## Junio C Hamano, 2013-01-23 20:24 Subject: Re: Question re. git remote repository Message-ID: <7va9rzhcl0.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7va9rzhcl0.fsf%40alter.siamese.dyndns.org In-Reply-To: <201301231941.r0NJf3oa001238@smtpb01.one-mail.on.ca> ``` "Lang, David" writes: > Thanks Matt and Dave and everyone else for your feedback on this. [administrivia: please wrap your lines to reasonable length] > 1. Download and install git for Windows on the 2 networked developer's > PC's and the 1 networked server. > > 2. On the server... > A) Initialize the Visual Studio folder for a particular > project as a git repository using 'git init' > b) 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' optionally: C) remove the original directory (A) D) make a non-bare clone on the server with "git clone", if you would like to have a single build environment on the server box. E) Use "git pull" from the bare repository you created in step (2.B) to update the repository you created in step (2.D) as necessary in order to build the latest in this repository. > 3. On each of the PC's... > A) Clone the remote repository from the network server using > git clone' (this will automatically create 'origin' as a remote source > on the PC's) B) Each developer works in his repository; use either "git pull" or "git pull --rebase" to sync up with the tip of the master repository as necessary; C) When a developer's work reaches a point where it is good enough to update the master repository, use "git push" to update the bare repository you created on the server in step (2.B). This may need to trigger step (2.E). > Couple of questions... > ... > 4. 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? These operations make copies and after making copies they do not ever refer to the original, so you can take a back-up of the original and remove it (i.e. optional step (c)). ```