Well, I think I understand some of the advantages of GIT like easy branching. I do not even bother to compare it to SVN because GIT is so much better.
I mean GitHub makes GIT even better; there are too many advantages and I just list a few of them here: 1. developers manage their own SSH keys on GitHub and you do not need to ask them to submit their public keys to you; 2. people who are not in the developer team can fork the project with one-click to their own repositories, change the code and send pull request online (instead of emailing patches) so that you can review the patch online; a very critical feature here is you can _discuss_ the code line by line with the one who submit this patch -- comments can be made in-between the code lines; if you are not satisfactory with the patch, you can require one to revise the code and resubmit; this process can go on and on until you are satisfied and accept the patch; see here for an example of my own: https://github.com/ramnathv/knitr/commit/33a75f4029 Personally I believe it is very inefficient to email patches and it is so inconvenient to discuss code in emails. If people send me pull requests on GitHub, I may merge them in a few minutes, but patches in email often lay in my inbox for months. 3. you can either discuss on GitHub pages, or directly reply the email notifications from GitHub about the discussions; the email will go to GitHub. This is unlike trac, you have to go to the web page to discuss (maybe there are configurations that enable trac to manage emails, but I did not see this happen in LyX SVN ages). 4. bugs tracker; they call "issues", which are also closely tied to code; you can write a commit message like "fixed #43" to fix the issue 43 (the issue will be closed and there will be a reference to the commit in the issue page); it is also more convenient to manage bug reports: one thing I do not like trac is I'm unable to change the report after I submit it (e.g. I want to add more code examples, or fix typos). 5. wiki support: you can manage wiki pages by GIT, or edit them online; the default aesthetics looks good (e.g. https://github.com/yihui/formatR/wiki) 6. GitHub pages: you can even manage your website on GitHub by creating a branch named "gh-pages" and use the Jekyll engine to compile markdown files to HTML (this is automatic on GitHub so you only maintain lightweight markdown files); it is easy to setup and after that, you can manage the website by GIT (see, everything on GitHub can go to GIT); sorry to use my own projects as examples again, but you can see the source https://github.com/yihui/knitr/tree/gh-pages of the site http://yihui.name/knitr/ for example Here is a recent article "Lord of the Files: How GitHub Tamed Free Software (And More)": http://www.wired.com/wiredenterprise/2012/02/github/all/1 In short, this is approximately true for me: GitHub = GIT + Trac + Wiki + Web and all are based on GIT. Anyway, this is just my 2 cents when I saw the transition from SVN to GIT, and of course you are free to invest time and efforts in setting up your own server. Regards, Yihui -- Yihui Xie <xieyi...@gmail.com> Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA On Fri, Mar 2, 2012 at 4:01 AM, Vincent van Ravesteijn <v...@lyx.org> wrote: > Op 2-3-2012 7:35, Yihui Xie schreef: >> >> I was actually wondering why not move to GitHub directly since >> everything is ready there and it saves a huge amount of server admin >> efforts... Maybe I missed some conversations earlier, but IMHO GitHub >> makes collaborations way way easier. >> > > In what sense does it make it easier ? Pull requests are nice, but this > requires all developers to read the mailing lists and to keep track of any > pull requests on github. It's easy to submit patches to the mailing list > using "git send-email". In this way, all developers can respond. > > Using git, you could acquire commit rights faster than using svn, because at > first you will be restricted to pushing branches like > "yihuixie/new-feature". This won't affect the source code until it gets > merged in by someone. > > Vincent
