On 18 December 2013 09:26, Vladimir Prus
On 18.12.2013 13:21, Mateusz Loskot wrote:
On 18 December 2013 07:55, Vladimir Prus
wrote: On 12.12.2013 02:19, Cox, Michael wrote:
Which brings me to a question I've been wanting to get answered: why was Github chosen in the first place? I know it's the 900-lb gorilla in public git repository hosts, but I think Bitbucket allows so much more flexibility in configuring your repositories:
- Individual branches and wild-card refs can be configured with who is allowed to commit (which can be a group).
Another problem with github model is that it promotes this fork-and-pull-request model, which then creates a history where every second commit is 'merged pull request N', which is not very useful.
IMHO, we've talked about it on IRC the other day, it may be useful as it helps to find out where things come from. A 'plain' contributed commit does not always carry useful information i.e. bug number it fixes. So, the merge commit is a chance to amend that.
I assume we're gonna follow proper commit message guidelines, line here:
http://git-scm.com/book/ch5-2.html
so the bug being fixed is part of the commit message. (If not, the commit is rejected).
OK, that is good indeed.
Plus, it indicates important detail: *who* let the contribution into the codebase.
You don't need pull requests for that, see:
https://github.com/boostorg/build/commit/5ce453de47ba732f5a88236f302370d7bba...
Git has separate information about committer and author, and github displays that.
Yes, that's right, my comment above was lazily expressed. I meant, *who* as there is link to Pull Request where complete cycle of review/updating commit/review is preserved. I know Boost allows use of PRs [1], but not sure if it allows use of corresponding features at GitHub for code reviews, etc. [1] https://svn.boost.org/trac/boost/wiki/StartModPatchAndPullReq
On the other hand, many other projects are using gerrit, where contributors clone locally, made changes and then push to a special magic ref on a server, which creates online review. Contributors of course can share their changes by pushing them to other repositories, but in the end, you end up with a clean logical patches to the official repository.
I have been a tiny contributor/lurker to Qt/Qt Creator, and from a contributor POV, their Gerrit system is a huge obstacle for ad-hoc or occasional contributors. Setting up is not easy, learning curve about the whole development workflow is quite steep, and the information is very distributed (no (auto)links between gerrit and their bug reports). For me, it is difficult to simply observe what is happening in the Qt/Qt Creator projects.
I don't recall my pain setting up Gerrit for Eclipse. But they do have some kind of cross-linking.
I guess it's matter of how Git/Gerrit/bug tracker is set up to play together. Best regards, -- Mateusz Ĺoskot, http://mateusz.loskot.net