Hi Dmitry and all

Thanks for taking time to explain me in details the philosophy of git
vs svn, it helped me a lot. Two comments/questions:

The first is that as you say,
quoted text
>'svn commit' does two things: it creates a new commit and propogate this changes to the server

This was a source of confusion for me and I did not get it
immediately. Maybe be help page git-svn crash course could be more
detailed about that? It just mentions the analogy git commit -a /svn
commit (so the first step you mention) but not the second (svn commit
is similar to git push also)? Personaly, I think this could help a lot
newbies like me ;-)

Second, you said
quoted text
> So, your normally should never push to the branch that is currerently checked out. (New versions of Git will warn you about that).

Is there a way to avoid that? Manually, do I just need on post A
(against which it was pushed from clone B) to use:
git-reset --hard HEAD

And if yes, can I automate that in hooks/post-update in A? Or post-commit in B?

Thanks a lot!

Matthieu

2009/7/30 Dmitry Potapov <dpotapov@gmail.com>:
quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html