Allow editor to be auto-opened for conflicts

[legrego]

Allow editor to be auto-opened for conflicts

[sorenlouv]

@legrego That's a great idea!

Specify editor
How do you think the user should specify their editor of choice? I think it could be done in the backportrc.json config where the user also specifies their credentials, or via the standard environment variables like $EDITOR and/or $VISUAL.

Prompt
The prompt is definitely an option but I'm leaning towards just opening the editor, if the user has specified one (that seems like confirmation enough).

Conflicting files
After your editor has opened, how do you determine the conflicting files? I always cd to the dir, and run git status to get an overview, and then fix them. Perhaps the output of git status should be displayed directly to the user, when a conflict occurs?

Finalising the conflict resolution
Currently the user is required to finalise the conflict resolution by staging and committing the changes. It would be great if the user didn't have to cd to the directory at all anymore - but I'm not sure how to accomplish this.
One option is that backport stages and commits automatically when the user clicks "enter". This could have unforeseen consequences (if they forgot to fix a conflict, which will now be committed).

[sorenlouv]

There is currently a check to determine if the conflicting files have been staged and committed. It is not possible to continue if this check fails but I can add a confirmation prompt to let backport do this automatically:

Backporting #28692 to 6.6
✔ Pulling latest changes
✖ Cherry-picking failed. Opening your editor `code` in: /Users/larry/.backport/repositories/elastic/kibana
? Press <enter> when you have resolved the merge conflicts Yes

The following changes will be staged and committed: 
--- a/animals.txt
+++ b/animals.txt
@@@ -3,3 -3,13 +3,16 @@@ canin
  dog
  cat
  mouse
+ horse
+ spider
+ elephant
+ dinosaur

? Continue? Yes
✔ Pushing branch legrego:backport/6.6/pr-28692
✔ Creating pull request
View pull request: https://github.com/elastic/kibana/pull/28701

_Note to self:

• use git --no-pager diff to get the diff, and git add -A && git commit --no-edit to automatically staged and commit with the original commit msg_
• list conflicting files: git --no-pager diff --name-only --diff-filter=U
• finalize cherrypick sequence: git -c core.editor=true cherry-pick --continue

[legrego]

Thank you for the thoughtful followup!

How do you think the user should specify their editor of choice? I think it could be done in the backportrc.json config where the user also specifies their credentials, or via the standard environment variables like $EDITOR and/or $VISUAL.

I'd prefer to set it in backportrc.json, that way it's more portable. I try to avoid environment variables, but that's probably just me :)

After your editor has opened, how do you determine the conflicting files? I always cd to the dir, and run git status to get an overview, and then fix them.

VSCode has a decent git integration which automatically shows me conflicts and staged files. For me, just opening the editor at the repository path would be sufficient.

For folks that want more, maybe this configuration setting is more of a command template, where we could configure something like: code ${repoPath} && git status?

Perhaps the output of git status should be displayed directly to the user, when a conflict occurs?

I'm not opposed to this, but if it's not too much work, maybe this is a configurable setting too? I like how concise the backport output is today, and throwing the output of git status in the middle of that would muddy the output IMO.

Currently the user is required to finalise the conflict resolution by staging and committing the changes. It would be great if the user didn't have to cd to the directory at all anymore - but I'm not sure how to accomplish this.
One option is that backport stages and commits automatically when the user clicks "enter". This could have unforeseen consequences (if they forgot to fix a conflict, which will now be committed).

Would we be able to leverage git diff --check to detect conflict markers before issuing the commit?

[legrego]

I like your second proposal to show the diff after confirming that merge conflicts are resolved!