Make consume a record #45450
Make consume a record #45450
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
punkratz312
changed the title
This comment has been minimized.
This comment has been minimized.
|
@geoand new we(ek) new we 🍀 its now mergeable right? |
If CI is happy, sure |
gastaldi
added
the
triage/waiting-for-ci
This comment has been minimized.
This comment has been minimized.
| : flags.with(this.flags); | ||
| return new Consume(buildStepBuilder, itemId, outputConstraint, outputFlags); | ||
| } | ||
| public record Consume(BuildStepBuilder buildStepBuilder, ItemId itemId, Constraint constraint, ConsumeFlags flags) { |
There was a problem hiding this comment.
Hey,
why is package-private visibility turned into public visibility? Is this class supposed to be used outside of this package with your changes?
There was a problem hiding this comment.
That's the reason I didn't merge this yet. I wanted to look at where this is actually used on my machine instead of my phone
There was a problem hiding this comment.
indeed, good finding even twice. thanks
|
Please squash all commits before we trigger CI again |
|
I have a question in mind. Since I need to squash locally and often run into issues avoiding merge requests, leading to simply creating new PRs, is it possible to adjust the settings to allow squash merging to avoid overhead? Or is the workflow intentionally designed this way? At OpenRewrite, it's convenient to squash away the work-in-progress commits since they don't matter after the final collaborative commit is ready to be merged into Here's a relevant reference: |
|
The workflow is intentionally designed that way, it facilitates the task of backporting commits to other branches |
|
Also please take a look at https://github.com/quarkusio/quarkus/blob/main/CONTRIBUTING.md#before-you-contribute to make sure you always rebase and avoid merge commits |
quarkus-bot
bot
added
triage/invalid
git rebase main
git rebase -i HEAD~3
|
|
I appreciate it! I executed it with 5 ^^, but it didn't look right. I only noticed it after the first push, of course. Let's get this done: As long as I don't change it, there's no need to rush—a rebase is possible anytime. Thanks for the support! |
|
Wow, even a video—thanks! For me, it's faster to handle this by creating a new branch, comparing it with the old one, grabbing the changes, and creating a new commit. |
This pull request reduces boilerplate code and eliminates unused code, addressing concerns related to code clarity and maintenance.
This change aims to streamline the codebase while maintaining functionality.