Hi, as there as a inquiry how to handle the situation here is one option:
Use the "Co-authored-by" trailer entry, as was done for example here: https://github.com/apache/netbeans/pull/5866/commits/697d0320eaffbd054813a5d0c369bf5ebae47703 ------------------------------------------------------ matthias@enterprise:~/src/netbeans$ git log -n 1 --pretty=fuller 697d0320eaffbd054813a5d0c369bf5ebae47703 commit 697d0320eaffbd054813a5d0c369bf5ebae47703 (origin/pr-5866, github/pr/5866) Author: Josh Juneau <juneau...@gmail.com> AuthorDate: Fri Apr 21 07:50:41 2023 -0500 Commit: Matthias Bläsing <mblaes...@doppel-helix.eu> CommitDate: Tue May 16 22:42:34 2023 +0200 NETBEANS-4035: CDI Bean as Named is not listed in xhtml for selection Closes: #4035 Co-authored-by: José Contreras <pepn...@apache.org> Co-authored-by: Matthias Bläsing <mblaes...@doppel-helix.eu> ------------------------------------------------------ The author was Josh, José and I contributed further changes, I did the squashing. All contributions are recorded here and are also correctly picked up by github UI. Here is the comment about/info about/motivation for the squasing: https://github.com/apache/netbeans/pull/5866#issuecomment-1550347489 Greetings Matthias Am Mittwoch, dem 08.01.2025 um 17:34 +0100 schrieb Matthias Bläsing: > 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
