Re: Question re. git remote repository
"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)). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question re. git remote repository
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-ow...@vger.kernel.org [mailto:git-ow...@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
Re: Question re. git remote repository
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question re. git remote repository
> -Original Message- > From: git-ow...@vger.kernel.org [mailto:git-ow...@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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question re. git remote repository
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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question re. git remote repository
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question re. git remote repository
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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question re. git remote repository
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question re. git remote repository
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:mse...@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-ow...@vger.kernel.org [git-ow...@vger.kernel.org] on behalf of Lang, David [david.l...@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 (da...@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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question re. git remote repository
On Fri, 18 Jan 2013, Matt Seitz wrote: From: git-ow...@vger.kernel.org [git-ow...@vger.kernel.org] on behalf of Lang, David [david.l...@uhn.ca] The other David Lang (da...@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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question re. git remote repository
From: git-ow...@vger.kernel.org [git-ow...@vger.kernel.org] on behalf of Lang, David [david.l...@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 (da...@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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question re. git remote repository
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question re. git remote repository
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:da...@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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question re. git remote repository
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:da...@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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question re. git remote repository
"David Lang" wrote in message news:... > >> > >> On Thu, 17 Jan 2013, Matt Seitz (matseitz) wrote: > >> > >>> 2. a repository where only one user does "git add" and "git commit", > >> while other users will do "git pull", the peer-to-peer model (you pull > >> changes > >> from me, I pull changes from you). > >> > > you may _be_ safe, and if others who really know the internals speak up, take > their word on it. Well, we already have Linus's article. I guess the question is whether the use case I describe above falls under: A. "maintenance operations" B. "normal git workflow" Personally, I would consider this use case to be a "normal git workflow". -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question re. git remote repository
On Thu, 17 Jan 2013, Matt Seitz (matseitz) wrote: From: David Lang [mailto:da...@lang.hm] On Thu, 17 Jan 2013, Matt Seitz (matseitz) wrote: 1. a bare repository that is normally accessed only by "git push" and "git pull" (or "git fetch"), the central repository model. pulling from it would not be a problem, I could see issues with multiple pushes taking place (the underlying repository would not get corrupted, but you will very quickly hit conflicts where the push is not a fast forward and you need to merge, not just push) How is that different on a network file system, as opposed to using http, ssh, or git-daemon? Don't you get a "not a fast-forward" error, regardless of the protocol? true. 2. a repository where only one user does "git add" and "git commit", while other users will do "git pull", the peer-to-peer model (you pull changes from me, I pull changes from you). pulling from a shared repository is probably safe, but I wouldn't bet against there being any conditions where a pull at the same time someone is doing an update being able to cause problems. Why do you think there would be a problem? The normal thing is to do the pulls through git-daemon, and that does make sure that what you are pulling is consistant. What does "git pull" via git-daemon do to ensure consistency that is different from "git pull" on a network file system? git pull via the daemon looks at what tree items you have on each end, and then it sends you the items needed to make you match the server. If there are partial updates on the server (due to some update in process) the daemon should not see that, but if you are grabbing the files directly, I would be less confident that you are always safe. you may _be_ safe, and if others who really know the internals speak up, take their word on it. But, absent assurances that we know that everything is done in the right order in the face of a networked filesystem (which may break visibility of changes due to caching), I would not trust such raw access for updates at all, and only somewhat trust it for read-only use. David Lang -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question re. git remote repository
> From: David Lang [mailto:da...@lang.hm] > > On Thu, 17 Jan 2013, Matt Seitz (matseitz) wrote: > > > 1. a bare repository that is normally accessed only by "git push" and > > "git pull" (or "git fetch"), the central repository model. > > pulling from it would not be a problem, I could see issues with multiple > pushes taking place (the underlying repository would not get corrupted, but > you > will very quickly hit conflicts where the push is not a fast forward and you > need to merge, not just push) How is that different on a network file system, as opposed to using http, ssh, or git-daemon? Don't you get a "not a fast-forward" error, regardless of the protocol? > > 2. a repository where only one user does "git add" and "git commit", > while > > other users will do "git pull", the peer-to-peer model (you pull changes > from > > me, I pull changes from you). > > > pulling from a shared repository is probably safe, but I wouldn't bet > against > there being any conditions where a pull at the same time someone is doing > an > update being able to cause problems. Why do you think there would be a problem? > The normal thing is to do the pulls through git-daemon, and that does make > sure > that what you are pulling is consistant. What does "git pull" via git-daemon do to ensure consistency that is different from "git pull" on a network file system? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question re. git remote repository
On Thu, 17 Jan 2013, Matt Seitz (matseitz) wrote: From: David Lang [mailto:da...@lang.hm] Linus says that git does not have "proper locking", so think about it, what do you think will happen if person A does git add a/b; git commit and person B does git add c/d; git commit? Sorry, I wasn't clear. My assumption is that a shared repository on a network file system will either be: 1. a bare repository that is normally accessed only by "git push" and "git pull" (or "git fetch"), the central repository model. pulling from it would not be a problem, I could see issues with multiple pushes taking place (the underlying repository would not get corrupted, but you will very quickly hit conflicts where the push is not a fast forward and you need to merge, not just push) 2. a repository where only one user does "git add" and "git commit", while other users will do "git pull", the peer-to-peer model (you pull changes from me, I pull changes from you). At this point only one system is writing to the repository and it doesn't matter that it's on network storage vs local storage. pulling from a shared repository is probably safe, but I wouldn't bet against there being any conditions where a pull at the same time someone is doing an update being able to cause problems. The normal thing is to do the pulls through git-daemon, and that does make sure that what you are pulling is consistant. David Lang -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question re. git remote repository
> From: David Lang [mailto:da...@lang.hm] > > Linus says that git does not have "proper locking", so think about it, > what do > you think will happen if person A does git add a/b; git commit and person > B does > git add c/d; git commit? Sorry, I wasn't clear. My assumption is that a shared repository on a network file system will either be: 1. a bare repository that is normally accessed only by "git push" and "git pull" (or "git fetch"), the central repository model. 2. a repository where only one user does "git add" and "git commit", while other users will do "git pull", the peer-to-peer model (you pull changes from me, I pull changes from you). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question re. git remote repository
On Thu, 17 Jan 2013, Matt Seitz (matseitz) wrote: From: David Lang [mailto:da...@lang.hm] On Wed, 16 Jan 2013, Matt Seitz (matseitz) wrote: Linus seemed to think it should work: http://permalink.gmane.org/gmane.comp.version-control.git/122670 In the link you point at, he says that you can have problems with some types of actions. He points out things like git prune, Linus wrote: You do need to be a bit careful if you do maintenance operations concurrently (I would suggest avoiding doing concurrent "git gc --prune", for example), but any normal git workflow should be fine. but I would also say that there are probably race conditions if you have two git processes that try to change the HEAD to different things at the same time. What makes you think there are race conditions? Linus wrote: And git doesn't have "proper locking", because it doesn't need it for database ops: git objects are stable. For refs, git should be using the proper NFS-safe "create and atomic rename" ops. As Linus points out, objects are stable, so when you create objects you don't have to worry about locking, if two things write an object at the same time, the same contents are being written so races don't matter. However, if you have two people doing a commit or merge, you will get different results based on the order they are happening in. This seems to be exactly the type of thing that falls into the 'maintinance operations' category. Linus says that git does not have "proper locking", so think about it, what do you think will happen if person A does git add a/b; git commit and person B does git add c/d; git commit? Since the tree will look different depending on what order these four commands execute in, the resulting HEAD could have multiple different values depending on the order. The individual commits may even be different. David Lang And "git init" specifically has a "shared" option: --shared[=(false|true|umask|group|all|world|everybody|0xxx)] I think this is dealing with multiple users _reading_ a repository, not making updates to it at the same time. The description of "shared" says "This allows users belonging to the same group to push into that repository." The "push" command is about making updates. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question re. git remote repository
> From: David Lang [mailto:da...@lang.hm] > > On Wed, 16 Jan 2013, Matt Seitz (matseitz) wrote: > > > Linus seemed to think it should work: > > > > http://permalink.gmane.org/gmane.comp.version-control.git/122670 > > In the link you point at, he says that you can have problems with some > types of > actions. He points out things like git prune, Linus wrote: You do need to be a bit careful if you do maintenance operations concurrently (I would suggest avoiding doing concurrent "git gc --prune", for example), but any normal git workflow should be fine. > but I would also say that there > are probably race conditions if you have two git processes that try to > change the HEAD to different things at the same time. What makes you think there are race conditions? Linus wrote: And git doesn't have "proper locking", because it doesn't need it for database ops: git objects are stable. For refs, git should be using the proper NFS-safe "create and atomic rename" ops. > > And "git init" specifically has a "shared" option: > > > > --shared[=(false|true|umask|group|all|world|everybody|0xxx)] > > I think this is dealing with multiple users _reading_ a repository, not > making > updates to it at the same time. The description of "shared" says "This allows users belonging to the same group to push into that repository." The "push" command is about making updates. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question re. git remote repository
On Wed, 16 Jan 2013, Matt Seitz (matseitz) wrote: "David Lang" wrote in message news:... 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. What leads you to think you will have problems? Why would there be more of a problem on a network file system as opposed to local file system that can be accessed by multiple users? There are safety checks and synchronization primitives that work between mulitiple users on one machine (where you can see what other processes are running for example) that don't work with separate machines using a filesystem Linus seemed to think it should work: http://permalink.gmane.org/gmane.comp.version-control.git/122670 well, he knows git better than I do, but using git over NFS/CIFS is not the same as saying that you have multiple users on different systems making changes. In the link you point at, he says that you can have problems with some types of actions. He points out things like git prune, but I would also say that there are probably race conditions if you have two git processes that try to change the HEAD to different things at the same time. And "git init" specifically has a "shared" option: --shared[=(false|true|umask|group|all|world|everybody|0xxx)] Specify that the git repository is to be shared amongst several users. This allows users belonging to the same group to push into that repository. When specified, the config variable "core.sharedRepository" is set so that files and directories under $GIT_DIR are created with the requested permissions. When not specified, git will use permissions reported by umask(2). I think this is dealing with multiple users _reading_ a repository, not making updates to it at the same time. David Lang -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question re. git remote repository
"David Lang" wrote in message news:... > 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. What leads you to think you will have problems? Why would there be more of a problem on a network file system as opposed to local file system that can be accessed by multiple users? Linus seemed to think it should work: http://permalink.gmane.org/gmane.comp.version-control.git/122670 And "git init" specifically has a "shared" option: --shared[=(false|true|umask|group|all|world|everybody|0xxx)] Specify that the git repository is to be shared amongst several users. This allows users belonging to the same group to push into that repository. When specified, the config variable "core.sharedRepository" is set so that files and directories under $GIT_DIR are created with the requested permissions. When not specified, git will use permissions reported by umask(2). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question re. git remote repository
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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question re. git remote repository
"Konstantin Khomoutov" wrote in message news:<20130116233744.7d0775eaec98ce154a9de...@domain007.com>... > On Wed, 16 Jan 2013 10:21:56 -0800 > Jeff King wrote: > > > > 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? > > 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. I'm a happy user of git on network file systems (NFS and CIFS/SMB), although not a heavy user. > 1. http://code.google.com/p/msysgit/issues/detail?id=130 I wouldn't be surprised if there are some subtle POSIX-Win32 compatibility issues here between msysgit and Samba (POSIX GIT, ported to use Win32 file system functions, sending those Win32 requests to a Samba server, and the Samba server translating those Win32 requests back into POSIX functions). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question re. git remote repository
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question re. git remote repository
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question re. git remote repository
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question re. git remote repository
On Wed, 16 Jan 2013 17:49:09 + "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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
