Hi all,
The sudden rise in commits for each PR is due to the mistake I made
yesterday when trying to merge a PR. I think I got the main branch as it
should be, but the one nasty side effect was that all pre-existing pull
requests had many additional commits that had already been merged. In terms
Thanks Shen.
got your point. Also encountered this problem.
It seems the all PRs created before yesterday will have a lot of commit
history in GitHub, it's so misleading.
Yes, the author may need to rebase it. So it will be clear like before.
Julian and Alessandro may not understand what you
Ah, I see, you’re talking about PRs like
https://github.com/apache/calcite/pull/3375 and
https://github.com/apache/calcite/pull/3393, which have 65 and 84 commits
respectively but should only have one or two.
Wow, I had no idea that force-pushes made such a mess.
Yes, I agree, it makes sense
Thanks to Julian and Alessandro for your reply.I agree with your point,maybe
I don't have a clear description of my thought.
Because we have a forced update of the main branch before, now almost every
PR on github has hundreds of File changes and dozens of commits, so it is a
bit difficult to
Hello everyone,
I share Julian's opinion about this, and I have seen other reviewers making
the same request (hold off from squashing while the review is in progress),
but never the opposite (please squash as there are many commits), but my
experience might just be anecdotal.
When I author a PR
I should have said that the current policy isn’t absolute. I agree that a
squash/rebase can be beneficial if there are many commits. It’s a trade off,
and the reviewer should make the call, not the author of the PR.
Julian
> On Sep 6, 2023, at 8:45 AM, Julian Hyde wrote:
>
> Personally, I
Personally, I don’t have a problem reviewing PRs that have many commits. The
GitHub web UI and command-like tools like *git diff main” make it easy to see
the whole change.
Conversely, if I have reviewed a PR and requested changes, I would much rather
that the author makes those changes in an
Hi devs,
I found that each PR has a lot of commits and file changed, which could
make it difficult to review. One approach is for the author of the PR to
rebase the latest code in the main branch and force push again. Best,
LakeShen
