On Wed, 7 Nov 2012 02:43:53 -0800 (PST)
John Smith <csos...@gmail.com> wrote:

> I'm new to git. I have to setup a master repo we are working on.
> I did the following.
> Created a new repo (non-bare) on my local machine (c:\work), unzipped
> the project, added the files, committed.
> I created a bare repo on our server (n:\work).
> Now I want to push from my local repo to the network repo, then my 
> collegues can clone the repo, then can pull and push.
> Is this approach good?

I suspect (looking at the second pathname) that by saying "created a
bare repo on our server" you meant "created a bare repo on a network
share provided by our server".  This actually might work but you should
be aware that's not a "standard" way to use Git (which is to install Git
on the server and provide access to server-side repositories using SSH,
HTTP and/or Git's own network protocol, or use some integrated solution
[*] which does the same thing in the end).

If you'll decide to go the Windows share route, at a minimum you must be
sure passwordless authentication works for each member of your team
when accessing that share, for when you access a remote repo using
either a network-mapped drive or a UNC path (//server/share/pathname)
Git will just call into the OS to access files at those locations, and
hence it's unlikely you'll see any authentication dialog if the SMB OS
subsystem will fail to authenticate you transparently.

The second possible problem is that it's hard to tell how reliably
Git will deal with the case of concurrent pushes to the same repository.
Git has been written for an OS providing POSIX semantics when accessing
a filesystem, so I'm not sure this maps perfectly to what is
provided/guaranteed by SMB.  I'd better ask on the msysgit mailing list
or on a main Git list.

I, personally, occasionally did *fetching* from Windows shares which
worked OK for me, but for real work I have a gitolite-based server setup
employing SSH access (the server runs Debian FWIW).  I'm aware this
might be suboptimal for a mostly-Windows shop, though.

[*] Some of them have been mentioned on this list recently: Git Web
    Access, GitLabs, GitBlit, gitolite.  Dig up the archives if you
    want to learn more.


Reply via email to