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"/<fill in your favourite 
name> repository. But ultimately, there shouldn't be a question of "if" you 
have a master repository but "where" you have the master repository, correct? 
Or in other words, it doesn't seem like you'd want to designate any one 
developer's local repository as also being the master repository, right? My 
sense is that would defeat the purpose of the DVCS.

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 

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?


-----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


> 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 

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).


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 

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 


The GitFaq wiki also says that using "git push" over NFS or CIFS/SMB is safe 
and reliable:


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

Reply via email to