4 ms·

> where you often have many iterations or the diffs are large). But for many other projects the UI that GitHub provides is sufficient GitHub is painful for non

> where you often have many iterations or the diffs are large). But for many other projects the UI that GitHub provides is sufficient GitHub is painful for non-trivial reviews. Biggest WTFs: - No comment threading (or at least collapsing). On a PR with 100 comments[1] it is unlikely that those revisiting the thread need to see (and download, and render...) the first bazillion comments. - Source "annotations" are lost after a force-push (why not keep around a read-only view of old comments? We have lost some valuable discussions on GH pull requests) Yes, we try to keep PRs small. But they also need to be meaningful, and sometimes they require (many) more reworks than expected. [1] https://github.com/neovim/neovim/pull/1820 https://github.com/neovim/neovim/pull/1820

falcolas 12y ago
Wait. Force pushes? That's a terrible habit to get into; force pushes have decimated more than a few a open source project's repository. https://news.ycombinator.com/item?id=6713742 https://news.ycombinator.com/item?id=6713742
- hk__2 12y ago
  What? Pull requests should be on their own branches, if you want to keep one commit per PR but need to edit it you must rebase it and thus force push. It’s a terrible habit if you’re sharing your branch with others, it’s completely normal if not.
- justinmk 12y ago
  Force pushes to the PR fork. We have set receive.denyNonFastForwards=true on the upstream master.
wereHamster 12y ago
> GitHub is painful for non-trivial reviews. That may very well be the case. But note how you said for non-tivial reviews, whereas in the presentation about go they said in general (see the line I quoted in my original comment). And argue that the vast majority of pull requests on GitHub are simple ones which don't need much discussion, so in general the GitHub UI works just fine. I don't have any hard numbers to back up my claim.
- enneff 12y ago
  > And argue that the vast majority of pull requests on GitHub are simple ones which don't need much discussion, so in general the GitHub UI works just fine. Right. And what you say validates my exact point: "pull request culture is not about code review." If all you want to do is cast your eye over it and click "merge", it works great. That's not how we work, though.
  - wereHamster 12y ago
    If you said "GitHub pull requests don't fit our culture" or "The GitHub pull request UI is insufficient for our needs" then it'd accept that. Both are perfectly valid reasons for preferring Gerrit. But placing this blanket statement about the whole "pull request culture" is just wrong.
    - enneff 12y ago
      We've spoken to GitHub about this. They're not happy with how PRs work, either. I stand by my statements.
      - xkarga00 12y ago
        I hope they are going to do something about it and someday see all the Go development happening on GitHub :)
drothlis 12y ago
> Source "annotations" are lost after a force-push (why not keep around a read-only view of old comments? We have lost some valuable discussions on GH pull requests) Yes, that is incredibly annoying. I discovered that if you add your comments in the "Files changed" tab (which shows the diff of the entire pull request) instead of the "Commits" tab (which shows the diff commit-by-commit), then the comments aren't lost when you force-push. Just FYI, might make life a bit easier if you're stuck with Github.

falcolas 12y ago

Wait. Force pushes? That's a terrible habit to get into; force pushes have decimated more than a few a open source project's repository. https://news.ycombinator.com/item?id=6713742 https://news.ycombinator.com/item?id=6713742

hk__2 12y ago
What? Pull requests should be on their own branches, if you want to keep one commit per PR but need to edit it you must rebase it and thus force push. It’s a terrible habit if you’re sharing your branch with others, it’s completely normal if not.
justinmk 12y ago
Force pushes to the PR fork. We have set receive.denyNonFastForwards=true on the upstream master.

wereHamster 12y ago

> GitHub is painful for non-trivial reviews. That may very well be the case. But note how you said for non-tivial reviews, whereas in the presentation about go they said in general (see the line I quoted in my original comment). And argue that the vast majority of pull requests on GitHub are simple ones which don't need much discussion, so in general the GitHub UI works just fine. I don't have any hard numbers to back up my claim.

enneff 12y ago
> And argue that the vast majority of pull requests on GitHub are simple ones which don't need much discussion, so in general the GitHub UI works just fine. Right. And what you say validates my exact point: "pull request culture is not about code review." If all you want to do is cast your eye over it and click "merge", it works great. That's not how we work, though.
- wereHamster 12y ago
  If you said "GitHub pull requests don't fit our culture" or "The GitHub pull request UI is insufficient for our needs" then it'd accept that. Both are perfectly valid reasons for preferring Gerrit. But placing this blanket statement about the whole "pull request culture" is just wrong.
  - enneff 12y ago
    We've spoken to GitHub about this. They're not happy with how PRs work, either. I stand by my statements.
    - xkarga00 12y ago
      I hope they are going to do something about it and someday see all the Go development happening on GitHub :)

drothlis 12y ago

> Source "annotations" are lost after a force-push (why not keep around a read-only view of old comments? We have lost some valuable discussions on GH pull requests) Yes, that is incredibly annoying. I discovered that if you add your comments in the "Files changed" tab (which shows the diff of the entire pull request) instead of the "Commits" tab (which shows the diff commit-by-commit), then the comments aren't lost when you force-push. Just FYI, might make life a bit easier if you're stuck with Github.