+0 , maybe -1 (I'm not sure yet) Sorry I'm late to the party... I see 6318 <https://github.com/apache/fineract/pull/6318> was already merged and will be reverted in 6336 <https://github.com/apache/fineract/pull/6336>. I'll still give feedback since I usually have strong opinions about git and sometimes they're even helpful opinions. :-)
Ádám Sághy wrote: > This feature would allow us to merge or rebase any open PRs with a single > click, ensuring that they are aligned with the latest HEAD. > By "us" you mean maintainers/reviewers, not necessarily the commit author/contributor, correct? I don't understand what change you were proposing. I thought we already had one-click merges. As for rebasing vs. merging, are we talking about making it easier to bring a PR branch up to date before merging to develop? I'd usually think to put that on the contributor/author, like: "please update your branch with the latest from develop" -- then *they* can rebase and force-push, or merge from develop to their PR branch. Either action is fine and will have the same end result AFAIK, albeit with a different commit history graph. I’ve overlooked a crucial issue: > > - If we’re rebasing, we lose the validity of the commit signature, which > blocks the PR. > If the contributor does the rebase locally, all the sigs and committer/author fields will belong to the committer/author. They'll just have to force-push and get another review approval. If a maintainer/reviewer does the rebase locally it'll change the commit's "committer" field to the maintainer/reviewer (leaving the author field unchanged) and replace sigs with maintainer/reviewer sigs (this is Good since they did rewrite history). Same, if the rebase is done on github, just with github's sigs instead. The last case is merging from develop into the PR branch. I didn't know there was a button for that, but it seems like that should work fine too. In all these scenarios the commits should still be signed. On the other hand, if we use merge commits, we’ll have at least two merge > commits in the history. > This is fine, IMHO.
