Re: [git-users] Recommendations on a windows-based GIT environment with a local server

2013-10-30 Thread my . sevenflip
Hi Magnus,
Thanks for your reply. So you say we should use a windows network drive or 
network share on a (server)computer with a normal standard git 
configuration for now? Why would you not use gitblit?
Is there any (easy) way to make sure that only one person may merge to the 
master/head branch?

Thanks, 
sevenflip.

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [git-users] Recommendations on a windows-based GIT environment with a local server

2013-10-30 Thread Konstantin Khomoutov
On Wed, 30 Oct 2013 02:43:14 -0700 (PDT)
my.sevenf...@gmail.com wrote:

 Thanks for your reply. So you say we should use a windows network
 drive or network share on a (server)computer with a normal standard
 git configuration for now?

Yes.  Just make sure you have transparently working authentication on
that share for everyone involved -- this means, that when each of your
devs fires up Windows Explorer on their box and navigates that
\\server\share UNC path, the remote system must authenticate them
automatically using that dev's user name and password, so that Windows
Explorer does not show any errors and does not pop an authentication
dialog.  This is needed because Git has no way to present the user
with the same dialog and attempts to access the repository will just
fail.

 Why would you not use gitblit?

Because you yourself told us it crashed on you.
Also, with the setup this simple (one repository, four users) using a
high-profile server side solution might be a bit too much for a start.

 Is there any (easy) way to make sure that only one person may merge
 to the master/head branch?

I would suggest you to not get obsessed with things like this for now.
This kind of problem largely exists only in centralized systems where
making wrong history requries involved fixing on the server side
using specialized tools.  Contrary to this, with Git, if someone
botches a branch in your central rendez-vouz repo, you would just
cook a correct one in your own local reposisotry and then force-push it
to the central one, essentially replacing the botched one.

In any case you might create a so-called post-receive hook in the
centralized repository which would check if a forbidden ref is
attempted to be updated and fail if the user who attempted this is not
the one allowed to do that.  Start with `git help hooks`.

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.