Git plugin - improve continue-or-commit guidance during rebase conflict resolution

[chrispitude]

I was walking a writer through pull-rebase conflict resolution. After we resolved the conflict:

image.png

I realized I was not sure whether to "continue" or "commit".

• From its name, the Continue rebase button seems to be the right next step.
• But remembering how regular Git works, could not committing a staged file result in lost work?

This question is not specific to Oxygen's Git add-on. I found it asked here:

https://stackoverflow.com/questions/220 ... e-continue

The official Git documentation for rebase conflict resolution at:

https://git-scm.com/docs/git-rebase

uses "continue" and not "commit". My guess is that "continue" internally performs a commit-amend to keep the description of the current local commit being rebased, whereas "commit" creates a new commit that discards that original local commit description. This is supported by the following documentation:

All changes made by commits in the current branch but that are not in <upstream> are saved to a temporary area. This is the same set of commits that would be shown by git log <upstream>..HEAD...
...
The commits that were previously saved into the temporary area are then reapplied to the current branch, one by one, in order.

Maybe either method will accumulate commits in this temporary area, which are then reapplied to the current local branch after the rebase is complete.

This "continue"/"commit" ambiguity can be dangerous. Because the Commit button is there and staging/committing works normally, we have had multiple situations where a writer ignores the Abort rebase and Continue rebase buttons and continues to edit and commit new work as if they are in a regular Git workflow - sometimes for days. This causes serious divergence issues because no unpulled commits are detected during this time, increasing the possibility of additional conflicts when they eventually complete the rebase and try to pull the upstream again (which has happened).

Perhaps this ambiguity could be resolved as follows:

• Hide the Commit button.
• Move the Abort rebase and Continue rebase buttons to where the Commit button was.
• Place the current local commit's description in the description box, and make it uneditable (because I think continuing a rebase does not allow an updated description?).

Maybe the description could be editable by having the Continue rebase button internally do a commit followed immediately by continue, but only if we are sure this is mechanically correct within Git and will not lead to other problems.

I filed a related Git add-on enhancement (#171: For detached HEAD, include commit details in commit SHA tooltip) to provide improved context to the writer during rebase conflict resolution.

I think we could give writers much more confidence when resolving rebase conflicts by (1) removing the "continue"/"commit" ambiguity, (2) showing the local commit-being-rebased description in the commit description box, and (3) showing the upstream conflicting commit description in the detached HEAD SHA tooltip.

A testcase is included:

git_rebase_conflict.zip

To run,

1. Create an upstream repo on a Git server that has a "main" branch and allows force-pushing.
2. Edit the make.sh script to point to the upstream repo.
3. Run the make.sh script.
4. Open the repo-local/oxygen.xpr file.
5. Do a pull-rebase.

[alex_jitianu]

Hi Chris,

Thank you for the detailed analysis. These rebase conflicts can be a challenge at time and the proposed changes would be a great help in this regard. I've recorded an internal issue for it (EXM-51951) and I will schedule it for a next release.

Best regards,
Alex