Re: How to push properly a la subversion

[Dmitry Potapov <dpotapov@gmail.com>]

On Thu, Jul 30, 2009 at 10:11:43AM +0200, Matthieu Stigler wrote:
> 
> Furthermore, there are reluctant to install any new softwares
> and to use command line software,

Actually, gitk and 'git gui' are very nice... Well, I do prefer the
command line, but I still use gitk to see the history. There are
some other GUIs out there, but they should be installed separately.

> I used for now portable GIT on windows,
> which seems to have also ssh.

ssh client works fine on Windows, but I have never installed a shared
repo on Windows, which would require to install a ssh server. So, I
don't think I can help here.

> So I understood that I need to set-up a shared repo, thanks for your
> advices! Now do I really need all those permissions issues? What is the
> simplest way to deal with that?

If you want to have a shared repo then every developer should have the
write access to it and every file created by any developer should be
writable by other developers in the same group. To prevent any developer
from removing anything on the server, they should not have the normal
access to it but only through git-shell (i.e. git-shell should be
specified as the login shell). Now, it is often inconvinient to have
many special users accounts. So, you can use gitosis, which requires
only one user account and identified users by their SSH key. I heard
that some people set up it on Windows, but it was Cygwin version of Git.

As to the simplest way, it is probably to use a distributed workflow:
each developer has their own repo, which is writable for him/her and
readable for other developers. (You can easily to do with sharable
folders by assigning appropriate permissions, and you probably will not
need to deal with SSH at all). In this workflow, every group has each
own team leader or co-ordinator, who is responsible for integration
other people work. Then the repo of the team leader will becomes the
"official" repo of the project, but it is only social a convention and
not a technical one. Any developer can fetch from any repository (see
also git-remote). IMHO, the distributed workflow is far superior to
having everyone to push to the same repo.

In fact, as closer you emulate SVN workflow, more SVN issues, you will
pick up. For instance, 'svn commit' does two things: it creates a new
commit and propogate this changes to the server. In general, it is a
very bad thing to do, because you end up with a lot of work-in-progress
commits, which may be steps in the wrong direction, but they interfere
with other people work. With Git even using a central repo, you can do
better -- developers can push their work when they have finished.
Still, you may want to have some code review process. How are you going
to organize that? And then when someone works on some feature or have
some other work-in-porgress, you still want that this work will be
properly backed up (or at least, store more than in one place). So, you
naturally want to give every developer repo on that server where he/she
can push their work _before_ it is become part of the official history
of the project. And, finally, it is always good to have someone who
co-ordinates everyone's efforts, so intergation will be not randomly but
based on priorities and quality of one's work...


Dmitry