Live data from Hacker News

More code review tools

github.com

131–140 of 151 posts

Re: More code review tools

#132
post #73
post #52

Earlier quoted context omitted.

That button only appears when you add new commits to the existing branch/PR. If you amend any commits and force push, the rewritten commits are lost forever on the GitHub side of things. You can only find them in your local ref-log at that point. Gerrit instead retains each rewrite of the "same" commit. It does this by requiring you to insert a "Change-Id: ..." footer into each commit message (it provides a repo hook…

Only comments on the commits are lost. Comments on the Files tab of the PR itself are kept and you can "View outdated diff". In our project we exclusively use comments on the Files tab precisely for that reason.

Well, I guess this explains why sometimes I saw comments on PRs disappear and sometimes they didn't, thanks.

The difference between commenting on the commit page and on the "files tab" is pretty subtle though...

Re: More code review tools

#133
post #21

It would be nice if GitHub supported a Gerrit-inspired code-review process, where instead of having to choose between: 1) piling new commits onto the existing branch/PR, or 2) force-pushing and completely losing the old commits on the server You could instead push into a "magic" ref-spec and the server would retain the original commits, but also the rewritten commits, such that a PR can have multiple revisions. This…

Exactly what I want. I basically abandoned GitHub's pull requests because of that.

Re: More code review tools

#134
post #6

Does anybody else feel like GitHub has released more features in the last month than the last 6 months? I'm not sure if it's just a coincidence with all the attention they've gotten on HN, but these improvements are much appreciated!

GitHub is still far behind GitLab.

Re: More code review tools

#135
post #24

Earlier quoted context omitted.

They're focused on turning that capital into recurring revenue! i.e. building out the GitHub Enterprise business This is pretty common among companies that make the consumer->enterprise transition. Also see Dropbox, Slack, etc.

> building out the GitHub Enterprise business None of what they just released impacts the GH Enterprise side of things. Maybe it will long down the line, but suffice it to say, none of this sells or keeps customers of GH Enterprise. The reality is, we've questioned our use of GH, and while we are still paying for GHE, it's more or less because it's just not expensive enough at this point to justify switching to somet…

> So yeah, if they are focused on GHE, these features don't suggest that.

Then have a look at the GHE release notes. 2.5 introduces clustering to improve scaling of large instances, which is really nice for large orgs like my day job in SAP Cloud Infrastructure.

Re: More code review tools

#136

I'd love it if there was a way for me to queue my comments before submitting. I often keep my comments in a separate textedit/nv window and then go back to put them in since I want to keep track of questions that arise as I'm reading, but I don't want to pepper someone with comments that would be resolved 200 lines later in the diff.

Are 200 line diff common? I feel like having focused patches are useful for everyone. Including git bisect and CI/CD.

Totally. Just click "rails generate" twice. ;)

Re: More code review tools

#137

Earlier quoted context omitted.

They removed full-commit comments on PRs, as opposed to line-level comments on either commits or diffs, or full-commit comments on non-PR commits, but I don't think anyone used those—I haven't even seen anyone use something that wasn't a line comment for a long, long time.

I've used commit-level comments before, but it is admittedly not very common.

It is very useful in work cultures where people don't do PRs all the time (particularly out of laziness or to do hotfixes), but you still want to comment on the change.

Re: More code review tools

#139
post #21

It would be nice if GitHub supported a Gerrit-inspired code-review process, where instead of having to choose between: 1) piling new commits onto the existing branch/PR, or 2) force-pushing and completely losing the old commits on the server You could instead push into a "magic" ref-spec and the server would retain the original commits, but also the rewritten commits, such that a PR can have multiple revisions. This…

Hey, I'm one of the devs for this new PR stuff. This flow is something we're hoping to improve as well. Force push support is pretty second class right now, any previous commits and discussion basically gets lost. It sucks. So we already use a internal refspec for tracking the latest PR HEAD. You can actually manually fetch this under `refs/pull/123/head`. However, this is only the latest HEAD, not any previous histo…

I have a somewhat shonky shell script which maintains a fast-forward branch that tracks the HEAD of a rebasing branch over time. I use it for keeping the history of a set of patches.

https://github.com/fanf2/git-repub

Re: More code review tools

#140
My biggest pet-peeve with GH code review is that line-comments are automatically folded whenever that line of code is changed. So if the changes to that line didn't relate to your CR or if they didn't actually fix anything, then your comment will pretty much be lost to time.

Plus, it would be nice to see the discussion around a particular line without having to go through the entire PR and unfolding each conversation to see if it's the right one.

Post reply on HN