-
Notifications
You must be signed in to change notification settings - Fork 309
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: sync v3 with main branch #822
Conversation
* chore: protect v3.x.x branch In preparation for breaking changes. * force pattern to be a string * simplify branch name
…#815) That warning should only be used when BQ Storage client is explicitly passed in to RowIterator methods when max_results value is also set.
…ields for BQML. (#817) PiperOrigin-RevId: 387137741 Source-Link: googleapis/googleapis@8962c92 Source-Link: googleapis/googleapis-gen@102f1b4
Co-authored-by: release-please[bot] <55107282+release-please[bot]@users.noreply.github.com>
I wonder if squashing is going to make resolving commits harder in the future? Ugh. |
Maybe we keep this PR open and periodically add merge commits so that we can resolve conflicts incrementally? |
Except for the fact that you just added branch protection to |
+1 for merging/rebasing |
Also, I'm not entirely comfortable with syncing changes from With that in mind it might actually be better to bring in the changes from Update: created. Was faster than tinkering with Tim's PR branch and to first send my changes there. |
@unittest.skipIf( | ||
bigquery_storage is None, "Requires `google-cloud-bigquery-storage`" | ||
) | ||
@unittest.skipIf(pyarrow is None, "Requires `pyarrow`") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is what I was talking about, i.e. "semantic conflicts". We should be careful to not let these through, since they do not necessarily create loud merge conflicts.
It can get tricky :/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch!
After resolving several semantic conflicts myself in the related PR, I think it will be easier to not keep a PR open for too long, but instead incrementally accumulate the changes from For example, I knew I had to pay attention to redundant skipIf decorators, because it was my code, but might have overlooked semantic conflicts in other people's contributions. The authors probably know best how to bring their changes to the |
Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:
Fixes #<issue_number_goes_here> 🦕