On Fri, Jul 22, 2016 at 09:57:37AM +0000, Dimitris Chloupis wrote: > No. > > It may surprise you but pull requests having nothing to with code review, > they are just a formality. > > To understand pull requests you have to understand character of the person > that created git, Linus , the man behind Linux.
Pull request is not a git concept and has nothing to do with git. It's an abstraction over merge. > easy going person, and he wanted a VCS that isolated developers rather than > bringing together under one roof as SVN is doing. Git was not the first DVCS; Linus & co. merely adopted system they were already using. > > Furthermore a pull request offers no practical advantage other than > isolation, you can review any commit done directly to the repo and revert > back the commits you dont like and open a discussion about it in the issue > tracker. This is factually false. Pull request is a group of interrelated commits, so while you can review individual commits, for anything larger than a bugfix reviewing individual commits is a waste of time. It's much easier to track changes and fixes after code reviews with a pull request. > And what makes pull request ever less uselful are branches Pull requests and branches are complementary. > Also pull requests come with a big disadvantage , fragmentation. Because > they lead to the creation of forks . Is this your first encounter with _distributed_ version control systems? Forks are fundamental aspect. > the fork only contains a handful of commits but a fork can easily deviate > without issuing any pull request back to main repo. Its similar to Squeak / > Pharo situation, the fork becoming more popular than the main repo. And in > the case on Squeak/Pharo is fine because the fork is only one, but a trip > to github disneyland will reveal a hell of forks especially for popular > repos. This can easily lead to "a war of forks". I don't see any problem here, it's OSS and people have different opinions, so forks are natural resolution. People often fork on github because they can or because they want to experiment with something, but there is no "war of forks". Running large OSS is resource-intense so common forks cannot and do not compete (e.g. bootstrap has 44000 forks, but none of them competes), And if they do compete then it's usually on fundamental opinion differences, or systemic problems that are best addressed with forks (e.g. lodash vs underscore). There is no problem with the fork surpassing it's predecessor, the community benefits from it in the long-term. Many different forks can be a pain for small under-maintained projects, because a fork can much more easily have an impactful change — so it's easy to have two or three forks with each having a different important feature. On the other hand due to it's small-scale, it can also usually be also resolved. If the original dev does not have the time and resources to manage it (which is too common since a lot of OSS are side-projects), then forks are inevitable. > Pull request essentially offer the advantage of isolation , when you have > hundred of developers trying to commit to the project you need some way to > keep the ones that you are not familar with out, this is why all very big > projects in github use pull requests but also have main contributors. For > much smaller projects say 5-10 people its not neccessary, since most likely > they will work in branches anyway and because merging to master will be > followed after a discussion in the issue tracker. We've successfully used pull requests in my previous company for years even on two-man projects, because they _can_ and do provide value. If you don't see it, or they are not valuable to you that's fine (Which can be easily true if you are a single dev/hobby programmer), but claiming that they are useless is just bullshit. Peter > > On Fri, Jul 22, 2016 at 11:17 AM Peter Uhnak <i.uh...@gmail.com> wrote: > > > On Fri, Jul 22, 2016 at 07:19:09AM +0000, Dimitris Chloupis wrote: > > > I see a pull request as a way to moderate commits by people that cannot > > be > > > trusted or that are not regular contributors. > > > > No. > > > > The purpose of pull request is to discuss and review the code. > > Code reviews should be done whether you are regular contributor or not, > > because it's valuable for both the code base, and all people involved. > > > > Furthermore if you have CI properly configured, then it can execute tests > > on the pull request so you know the code is healthy. > > > > Of course if you work alone or have this is a fun OSS side-project, then > > no rules apply. > > > > Peter > > > >
