It seems like these people simply don't understand Github very well.
Can only view diffs on a single page (can be very slow).
Cannot compare differences between patch sets.
Accepting a patch creates a "merge commit" (ugly repo history).
Don't use the merge button, just add the requester's repo as a remote to yours and use your familiar tools. If possible and done, a fast-forward merge + push will also close the PR.
Comments are sent as they are written; you cannot "draft" comments.
How is that different from pull requests via emails? (Also, on the website itself the comments can be edited.)
To create a patch one must fork the repository publicly
(weird and unnecessary).
What exactly is weird about that? It makes it possible for the requestor to craft their changes with full control, without requiring upstream to give them write access. This point is just entirely nonsensical.
In general, pull request culture is not about code review.
A strong claim, but one without any justification, and which is, in my experience, as far from the truth as possible.
Edit:
In light of their complaints about the need to fork, i have to say that their current contribution process can in its entirety be described as weird, unnecessary and baroque:
> Don't use the merge button, just add the requester's repo as a remote to yours
Actually, you don't need to do that. GitHub provides a special pulls remote "namespace" on the upstream repo, so you can add it as a fetch pattern to your .git/config like so:
Wow you are my new favorite person. What I was going to say was that the GP was correct in that it just took a bit more work on the maintainers part to keep the history clean, but even that is unnecessary apparently :-)
>> Comments are sent as they are written; you cannot "draft" comments.
> How is that different from pull requests via emails? (Also, on the website itself the comments can be edited.)
With github PRs, notifications are sent as soon as you write your first comment; in systems like gerrit and rietveld (and email) they are not sent until the reviewer chooses to send them. This leads to either awkward interactions if you start replying to comments while the reviewer is still reviewing, or unresponsiveness if everyone introduces hysteresis to avoid this situation.
This is IMHO the biggest problem with Github PRs; I don't necessarily agree with the Go team's decision to abandon the PR system but on smaller projects I have pushed for rietveld over PRs for this reason.
1:12pm line 33: Why are you doing this?
1:13pm line 33: I see, sorry, ignore my earlier comment.
A system that lets you draft comments and then send them out in a batch can avoid a bunch of noise. On the other hand, though, people who aren't expecting it can get stuck with draft comments they don't send out.
Half your post is saying we should just use different tools, but we are. We're using Gerrit, that lets us work the way we want.
On the contributor instructions: note that if you just want to use plain git (and not our git-codereview tool) then you can stop at "Register with Gerrit."
We created the tool to provide a more familiar review process for the people that used our previous system.
If we took your advice and used offline diff tools, etc, we would need a similar page explaining how to do all of that. None of this convenience comes without an up front cost.
Thanks for the direct answer. I think my stance wasn't clear enough, so i'll reword what i wrote in another comment here.
My issues are two-fold:
You could have just said on that slide: "We want a central code review system, so people do not have to learn Git. Github isn't terrible, but Gerrit is much better."
Instead you ended up putting up a list of points that make github seem like some kind of fatally flawed thing, while frankly putting people off with inaccuracies/subjectivities.
Secondly, by not allowing things by github you're forcing people to learn something else. Most developers experienced with Git will also be very familiar with Github. You're telling those people to instead go and learn something else. That will result in some people deciding it's not worth the trouble. I'm fully aware it's up to you to decide whether you're willing to pay that price, but personally i find it a bit odd that you can't simply do both.
And as for, apparently, most of the documentation on your contribute page being safely ignorable: If that is truly the case, i recommend rewriting that to make it obvious, because right now it's anything but. :)
If the last bit is the only good thing that comes out of this, then i'll be happy.
I have no idea what they specifically mean, but I can tell you, that the github requirement of pr to come from public repositories on github is something that bothers me occasionally. There are lots of reasons why I may not want my github fork to be public or I don't want to have a github fork at all but do want to contribute to a repo hosted there. This is a distributed version control system we are talking about after all.
As for their claim about pull request culture, again I'm not sure what they specifically mean, but I find the github code review tools to be very rudimentary and suspect that lots of other people with experience with more sophisticated code review workflows feel the same way. Github is a great service for some things but it certainly is not centrally about code review.
I also am scared off by the public aspect, and find it a very awkward requirement. If there was an option to create a private branch on Github, I'd probably use it often. I'd love if there was an easy way to submit a quick patch using only the Github interface. As it is, I've clicked once in my life on the fork button, realized that it created something visible to the outside world, and have never used it again. Instead, I make a local checkout, and generate patch files.
It's difficult for me to explain why I feel this way. The original stigma of 'fork' is definitely part of it, but most of it is just my distaste for visibility: it feels horribly immodest to associate myself with a project with which I probably have only a passing association. I can't defend my attitude, but it's probably worth noting that people like me (and apparently the author of the Go article) will be dissuaded if public affiliation is a requirement.
Now this is an interesting answer and i thank you for it. You don't have a problem that is in search of a solution. You have a real reason why github's publicity can actually be a bit hindering.
And i am even more grateful because it's truly a way i have not yet considered. See, for me github is a tool that i approach as dispassionately as my garage door opener. It is a thing with which i personally solve problems. Those problems are broken software or broken documentation. I use github to fix things. And i'm almost always doing so with a sense of nearly full confidence in that my issues or PRs will either fix a problem, or allow me to gain information so i can fix it. The only doubt i have is when i recognize the maintainer is not very skilled or otherwise mentally a little of the beaten path and might need some convincing.
The least concern i ever have is "someone might see what i'm doing", which is why i've ended up with 210 forks in my account. I didn't think that concern could ever be a thing since i started using Github long after the time when i last had reason to feel truly self-conscious about the code or documentation i'm creating, and you did remind me of the time before that point, so i can understand you now.
Maybe with time it will get better for you, maybe not. Please keep sending emails with patch files if that's what you feel most comfortable with.
I think that it's a little bit of a problem with a lot of the modern "social web" mindset; it all implies that you should feel comfortable doing everything in public, with the whole world watching you.
The problem is, there are people for whom this really doesn't work well. Some might just personally feel uncomfortable about it. Some might be concerned about future career prospects. Some might be women, who are worried about online harassment. Some might be people with stalkers, who are trying to avoid any kind of traceable online public trail.
This whole "share all the things" mentality leads to somewhat creepy exposure of everyone's private lives to governments, corporations, the general public (which can act as a mob on occasion), and also specific private individuals who you might be trying to avoid exposing things to.
The simplest reason is if what I was contributing was done on my employers time and they have strict IP restrictions. It is much, much easier to vet a single changeset than it is to a) verify a whole repo history and b) coordinate around my public/private github identities.
I'm not sure I understand. Vetting a changeset is basically the same thing as verifying the repo. Just look at the hash of repo A (your clone), check that it matches B (upstream), check that your repo A + "patch" matches pull request.
I was hoping for more reasons, since the very first and simple one is usually the one that has the most and simplest workarounds. You could for example make a patch with git on your local machine and attach that to an issue.
If PRs were a instantaneous thing, I don't think it would be a problem. However, if you've ever looked at a network graph of a repo that requires rigorous code review or doesn't have a diligent maintainer, some of those forks can sit in limbo for a really long time. And, as more pull requests pile up, it's very difficult as a user to figure out which version I should be using for my code to run correctly.
I just ran into this issue the other day when I was using Node with a lot of dependencies that still haven't been patched for issues that cropped up in OSX Yosemite.
> it's very difficult as a user to figure out which version I should be using for my code to run correctly.
I've rarely had trouble with assuming master (or ideally a tagged release) on the original repo (not a fork) is the one I should be using. Assume all forks are forks.
In any cases where this hasn't been true, it's been clear to me the blame is due to poor release management (or poor communication of release management, which is the same thing), rather than somehow the fault of github's PR or forking system. Although you can hypothetically argue that certain UI's encourage poor release management and others support it, I personally have not seen this to be an issue in github's UI.
Github didn't always distinguish well between repos you'd substantially authored and long-lived off-hand pull request forks. This made it annoying as a showcase of your work. Fortunately, they've made things much better now.
Creating the public fork and pushing to it is among the last parts of the process of making a contribution in my process. At that point you're making your changes public anyway, so I don't undersand this concern at all.
This is the smell of git plumbing again. Don't use the obvious UX that's been presented to you, do some other workflow that doesn't appear in the documentation.
For many developers the only reason we use git is github. I for one much prefer mercurial but to collaborate with others (and now for my job) github is a de facto standard.
Well, it depends on what documentation you mean. The alternative is using standard git commands that are in the git documentation, which is exactly what OP's alternative presumably involves?
(But I am entirely sympathetic to the opinion that git itself exposes too much plumbing and has a pretty baroque end-user interface for doing certain things. And it's also certainly legit to wish or suggest that _github_'s UI worked differently than it does, although the merge commits don't really bother me, and some people prefer them, it's a point of some contention).
I see you've been downvoted and I think unfairly. I agree with you though.
Looking back at arguments people make about how to "do it properly", it looks like something is broken. Git is broken, maybe Github is broken, documentation, UI, marketing. Something is though. When an obvious UI element is there, seemingly designed to do merges, and then everyone says "no, no, do this other thing", like send emails, then rebase here on top of that, make a ref pattern in your ~/.gitconfig ...
I must admit i have not, and to make clear: I am not taking offense to their implication that Github is worse at some things than other tools (it is). My post above is merely objecting to the opinions that were borne out of some lack of knowledge (which is acceptable), yet are posited as facts (which is not).
Mm, I'm not sure. These are slides, presumably designed to go alongside a talk, which could have fleshed out the points better. If you consider them as being summaries of what a speaker's saying, it makes much more sense.
Fwiw, of the six bullets, I see three which are clearly subjective, one which is a clear advantage of gerrit, and two which I don't really know enough about to refute.
When it comes down to build systems, I think it's very easy to spend a lot of time moving sideways or backwards - and if the tool you're moving to has deficiencies compared with what you had before, it can be very frustrating. Certainly, if the tool people want you to move to offers few advantages over your current infrastructure, a quick dismissal is reasonable.
Getting set up with their current contribution system might seem a little clunky, but I don't think it's particularly hard to do, and definitely seems like a 'run-once' thing. Once it's set up, it seems to integrate into a workflow well.
Their contributors will have their current workflows set up nicely - and unless github's issues system has compelling advantages, it's definitely not worth them switching due to the temporary loss in productivity.
I'll concur that the GitHub code-review UX is atrocious. Having used a small number of other code review tools, I can't fathom how GitHub's tooling is so brain-damaged.
It does a few cute and clever things, but I totally agree with this slide deck's gripes. Email and GitHub are not really compatible.
These are all common issues with people that came from a different CVS and didn't learn what was different about git. They just learn enough to reach parity with the "everything is linearly developed" workflow.
When you live with that assumption, things like merge commits and pull requests seem silly and overkill since you live in the "patch is developed/reviewed in isolation" world.
It's not exactly the first the time Go team is showing that they haven't spent much time researching current practices, theory, research and tools in the field of software engineering.
Everything about the language screams of coming from minds who stopped learning new things in the late 90s.
I think you mean s/researching/adopting/, since you are only referring to the outcome, not the study or decision making that arrived at the outcome. The Go team generally knows about modern things; we deliberately choose not to use them when we don't think they suit Go.
--------------
It seems like these people simply don't understand Github very well.
Don't use the merge button, just add the requester's repo as a remote to yours and use your familiar tools. If possible and done, a fast-forward merge + push will also close the PR. How is that different from pull requests via emails? (Also, on the website itself the comments can be edited.) What exactly is weird about that? It makes it possible for the requestor to craft their changes with full control, without requiring upstream to give them write access. This point is just entirely nonsensical. A strong claim, but one without any justification, and which is, in my experience, as far from the truth as possible.Edit:
In light of their complaints about the need to fork, i have to say that their current contribution process can in its entirety be described as weird, unnecessary and baroque:
https://golang.org/doc/contribute.html