On Tuesday, August 6, 2013 1:37:40 PM UTC+2, Cactus wrote: > > On 06/08/2013 10:07, Jean-Pierre Flori wrote: > > > [snip helpful detail] > > Thanks JP, I will study how you work in the hope that I might get to > love GIT! > > However, with SVN it is much easier to manage the definitive MPIR than > it appears to be with GIT. > > For example, I am the primary manager of the stuff in the directories > build.vc<n>, and mpn/x86_64. In SVN I don't have to rely on anyone else > to ensure that MPIR is fully up to date in respect of these directories > - I just push my stuff to the SVN repository. > > But with GIT I have to tell Bill every time I want to change 'my stuff' > in the definitive MPIR and hope that he has the time to fetch and merge > this into his repository. Alternatively Bill has to constantly monitor > my GIT repository for changes to 'my stuff' and merge it into his > repository. Ans, as with the INTEL_COMPILER macro issue, how does Bill > (or anyone else) know that I have fixed it? In contrast with SVN I just > fix and commit it and its done! > > And, assuming that Bill is the MPIR manager, in order to maintain a > definitive version of MPIR he has to either rely on us to tell him that > he needs to take stuff from us or he has to constantly monitor what we > are doing. And we have to rely on Bill to do this management work - > work that is not even necessary with SVN! > > So I really don't see what benefits GIT has bought for MPIR when > compared with SVN. Unless we can use GIT in an SVN like fashion with a > central repository that we can all commit to, GIT just adds a management > overhead that doesn't exist with SVN. > > I think it is possible to give write access to a bunch of people to a given repository, not sure though on how to do that on github or even if that's possible. It seems that github (not git itself) was rather thought with the following in mind: "there is a canonical repo with a unique admin, other devs fork it and send pull requests", which is exactly what you don't like :)
If you setup a git server yourselves, then you could give write access to a bunch of "admins" easily. Then you could just put your experimental stuff onto your github repo when you want to give it some publicity but not yet include it in the definitive version of MPIR. And when you feel confident enough push that to the definitive repo without having to rely on Bill or anyone else merging it for you. -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/groups/opt_out.
