GitLabClient already handle commit order reversing, so re-handle it in
Runner causes cherry-pick order on GitLab to be wrong.
Remove commit order handling from Runner, and instead handle difference
between GitHub and Codeberg inside GitHubClient.
Now, since the default of --bp-branch-name takes the commit list from
{GitHub,GitLab}Client directly, that means backporting branch name
on Codeberg will also be changed to have commits in the correct order
too (old to new, in line with GitHub and GitLab), which is IMO a nice
bonus.
The auto-no-squash option is added to:
* backport all the commits when the pull/merge request has been merged
* backport the squashed commit otherwise
It is equivalent to dynamically adjust the value of the no-squash
option, depending on the context.
The no-squash option is kept for backward compatibility for a single
use case: backporting the merged commit instead of backporting the
commits of the pull/merge request request.
Detecting if a pull/merge request was squashed or not depends on the
underlying forge:
* Forgejo / GitHub: use the API to count the number of parents
* GitLab: if the squash_commit_sha is set, the merge request was
squashed
If the pull/merge request is open, always backport all the commits it
contains.
Fixes: https://github.com/kiegroup/git-backporting/issues/113
Co-authored-by: Andrea Lamparelli <a.lamparelli95@gmail.com>
