Question re. git remote repository

Question re. git remote repository

[Lang, David]

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.

Re: Question re. git remote repository

[Konstantin Khomoutov]

On Wed, 16 Jan 2013 17:49:09 +0000
"Lang, David" <David.Lang@uhn.ca> 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

Re: Question re. git remote repository

[Jeff King]

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

Re: Question re. git remote repository

[Konstantin Khomoutov]

On Wed, 16 Jan 2013 10:21:56 -0800
Jeff King <peff@peff.net> 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

Re: Question re. git remote repository

[Stephen Smith]

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

Re: Question re. git remote repository

[David Lang]

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

RE: Question re. git remote repository

[Lang, David]

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.

RE: Question re. git remote repository

[Matt Seitz]

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

RE: Question re. git remote repository

[David Lang]

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

RE: Question re. git remote repository

[Lang, David]

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

RE: Question re. git remote repository

[Matt Seitz]

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

RE: Question re. git remote repository

[Lang, David]

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.

Re: Question re. git remote repository

[Junio C Hamano]

"Lang, David" <David.Lang@uhn.ca> 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)).

RE: Question re. git remote repository

[David Lang]

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

Re: Question re. git remote repository

[Junio C Hamano]

David Lang <david@lang.hm> 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.

Re: Question re. git remote repository

[David Lang]

On Fri, 18 Jan 2013, Junio C Hamano wrote:

> David Lang <david@lang.hm> 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

Re: Question re. git remote repository

[Junio C Hamano]

David Lang <david@lang.hm> writes:

> On Fri, 18 Jan 2013, Junio C Hamano wrote:
>
>> David Lang <david@lang.hm> 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.

Re: Question re. git remote repository

[Philip Oakley]

From: "David Lang" <david@lang.hm>
Sent: Friday, January 18, 2013 9:27 PM
> On Fri, 18 Jan 2013, Junio C Hamano wrote:
>
>> David Lang <david@lang.hm> 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 

RE: Question re. git remote repository

[David Lang]

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

Re: Question re. git remote repository

[Jeff King]

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

Re: Question re. git remote repository

[David Lang]

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

Re: Question re. git remote repository

[Matt Seitz (matseitz)]

"Konstantin Khomoutov" <kostix+git@007spb.ru> wrote in message news:<20130116233744.7d0775eaec98ce154a9de180@domain007.com>...
> On Wed, 16 Jan 2013 10:21:56 -0800
> Jeff King <peff@peff.net> 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).

Re: Question re. git remote repository

[Matt Seitz (matseitz)]

"David Lang" <david@lang.hm> wrote in message news:<alpine.DEB.2.02.1301161459060.21503@nftneq.ynat.uz>...
> 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). 

Re: Question re. git remote repository

[David Lang]

On Wed, 16 Jan 2013, Matt Seitz (matseitz) wrote:

> "David Lang" <david@lang.hm> wrote in message news:<alpine.DEB.2.02.1301161459060.21503@nftneq.ynat.uz>...
>> 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

RE: Question re. git remote repository

[Matt Seitz (matseitz)]

> From: David Lang [mailto:david@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.

RE: Question re. git remote repository

[David Lang]

On Thu, 17 Jan 2013, Matt Seitz (matseitz) wrote:

>> From: David Lang [mailto:david@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.

RE: Question re. git remote repository

[Matt Seitz (matseitz)]

> From: David Lang [mailto:david@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).

RE: Question re. git remote repository

[David Lang]

On Thu, 17 Jan 2013, Matt Seitz (matseitz) wrote:

>> From: David Lang [mailto:david@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

RE: Question re. git remote repository

[Matt Seitz (matseitz)]

> From: David Lang [mailto:david@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?

RE: Question re. git remote repository

[David Lang]

On Thu, 17 Jan 2013, Matt Seitz (matseitz) wrote:

>> From: David Lang [mailto:david@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

Re: Question re. git remote repository

[Matt Seitz]

"David Lang" <david@lang.hm> wrote in message news:<alpine.DEB.2.02.1301161843390.21503@nftneq.ynat.uz>...
> >>
> >> 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".