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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html