On 1/8/25 12:11, Chris wrote:
Thx for the headsup. I know that pain but I thought that this is just
the button "squash and merge" at github, isn't it?
Well, not really. That method has it's own issues and we disabled that.
Cheers
Chris
Am 08.01.2025 um 18:33 schrieb Michael Bien:
+1
checking the PR commits is also part of our PR approval and merge
checklists:
https://cwiki.apache.org/confluence/display/NETBEANS/PRs+and+You+-+A+reviewer+Guide
if the PR isn't squashed properly it either shouldn't get approved, or
approved with a request to squash (there is also a label for it).
-mbien
On 08.01.25 17:34, Matthias Bläsing wrote:
Hello,
I'd like to ask you squash PRs before merge sensibly.
While a PR is in review, adding commits to a PR makes sense, so that
reviewers can see what changed and why. This also allows for
incremental improvements while the PR is open and thus supports
development. It can also make sense to merge master into a PR when the
two states diverged too much.
On the other hand there are drawbacks:
- A PR consisting of many commits makes it hard to revert it,
if necessary. There is always the chance to miss a commit, causing
unexpected results.
- The same is true for merges from master. Reverting a merge commit is
ugly and makes it even harder to revert.
- While in review the incremental changes are the most important part,
in the history, possibly year later, the big picture of the changes
becomes more important. If that is spread over 10+ commits it is
hard
to see what was done and if a merge commit is in that range it gets
nearly impossible.
There are projects, that squash every PR into a single commit. The
prime example is the OpenJDK project.
From my perspective there is a sensible middle ground: Squashing
commits inside a PR into logical units. We have had multiple PRs, where
cleanups of the affected source files and the actual changes where
done. In that case it makes sense to split the cleanup, which should
not change behavior, from the actual behavioral change.
Cleaningup with git is not that hard:
- If there are merges from master, rebase the changeset onto master
- Then use the interactive rebase feature of git to cleanup the commits
as necessary. Commits can be reordered and squashed together.
- Then force-push into the original PR branch
A diff between the original HEAD and the squashed HEAD can verify, that
there were no code changes missed.
If anybody needs help with that, it can be provided.
Thank you for taking time to read.
Greetings
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
