nastra commented on PR #5312: URL: https://github.com/apache/iceberg/pull/5312#issuecomment-1204851431
> I suggest the following order: > > 1. Squash all commits (if you're going to do this, might as well do it first). > 2. Rebase against master at commit before [99b41eb](https://github.com/apache/iceberg/commit/99b41eb9fbae1eb6c0501ce1fd1c9008893583b4) (otherwise build will fail due to spotless being enforced) -- I normally build after the rebase to make sure the rebase is correct. > 3. Rebase against HEAD of master. > 4. Run `./gradlew spotlessApply`. I would build after that. > > If we are going to rebase against master twice, before the spotlessApply ("Big Bang") and then to HEAD, in the first rebase, the code base has not yet been updated to the new style, so running `./gradlew spotlessApply` after this rebase means you're going to change a ton of files (correct me if I'm wrong, but `./gradlew spotlessApply` would apply to everything, right?). Why do this when you're going to rebase again on HEAD where the "Big Bang" has happened? I'd think you want to run `./gradlew spotlessApply` at a point where it'd at most modify the files that are added/modified in your change. The idea with squashing is to include all the changes from running `./gradlew spotlessApply` locally, so yes, this will change a ton of unrelated files, including the ones that are being modified for a PR. If you add those formatting changes into your commit and then do a rebase against latest `master`, then the only diff that should be left is the actual files that have been modified for that particular PR. This should minimize the amount of merge conflicts to an absolute minimum. On the other hand, if you rebase changes (that are formatted with the old style) against latest `master` before locally applying `./gradlew spotlessApply`, then you'll certainly will have more conflicts (consisting of style + code changes). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
