support backport, committing conflicts

[mvayngrib]

support backport, committing conflicts

[korthout]

Hi @mvayngrib This is a great idea, which I'm sure my team would love as well. It will reduce the manual effort of opening the pull request and such.

As conflict can exist in any of the commits, I think it would be best to commit and push the conflicting commit and provide instructions in the pull request on how to resolve the conflicts and continue cherry-picking.

I'll keep this issue in mind when planning new feature work. Of course, I'd be happy to receive a contribution for this as well. Either way, thanks for the great suggestion.

[vermz99]

@korthout I'll give this a try, if you have additional information, feel free to add them.

[vermz99]

Here's what i currently have in mind, after investigation:

Proposition

1. cherry-pick every commit up until the first conflict encountered.

2. DO NOT commit the actual commit conflict.

• As I see it, this would put additional burden on the user to actually figure out which files contains a conflict and then make sure to correctly remove comparison operators (i.e. <<<<<<<). Some IDE (i.e., VSCode) natively detect said operators as soon as you open a file and propose you to resolve the conflict, but not all of them do that (i.e., Visual Studio).

3. push the branch

4. Proceed to create the PR as DRAFT

• May add a label too? I'm open to suggestion.
• I really want to avoid the user to merge an unresolved branch. My fear is that this workflow allows the user to approve his own backported PR in repos where only 1 reviewer is needed. The original user could commit this unresolved PR without another review if he does not push anything on the backported branch. At some point it might be a good idea to request reviews from the original approvers when creating the PR, but that would require additional work outside of the context of this issue.

6. Provide a set of instructions in the Draft PR to continue the cherry-pick.