Pressing 'Continue' during 'Merge in progress' discards (without warning) any edits in commit-message

[goran-w]

When I perform a merge using option "Don't commit (Merge without commit)", SourceGit enters a mode "Merge in progress" (which can be Aborted or Continued).

In the LOCAL CHANGES view, the commit-message Subject is then pre-filled with a default title (describing the merge, including src and dst branch).

However, if I edit the commit message Subject and/or Description and then press the CONTINUE button, then a Commit is made - but with the default commit-message Subject, and any edits I made to the commit-message are lost without warning. (To preserve my edits, I would have had to first make a COMMIT (using the dropdown at the CONTINUE button) before pressing CONTINUE.

NOTE: Actually, separating COMMIT and CONTINUE here seems redundant and confusing. Ideally, specifically for this mode, there could be a single button "COMMIT & CONTINUE" or similar, which also takes any commit-message edits into account?

[love-linger]

This is why the Continue button was not placed with Commit in the first place. The Continue button is just bound to the `git merge/rebase/revert/cherry-pick --continue' command. The filled commit message will not be applied.

[goran-w]

Well, that's not how it looks now - the banner has only ABORT while the CONTINUE is a green button in the bottom right. Needs some clarification / guardrails to avoid losing commit-message edits.

[love-linger]

It's because of #693

[goran-w]

Yes. But where is the default commit-message coming from? It gets pre-filled in the edit boxes, so could it not use any edits done to it as well?

[love-linger]

It's readed from the .git/MERGE_MSG or .git/rebase-merge/message based on current in progress state.

[goran-w]

From the git merge docs:

git merge --no-commit
This can be used when you want to include further changes to the merge, or want to write your own merge commit message.

Use git commit or git merge --continue to seal the deal. The latter command checks whether there is a (interrupted) merge in progress before calling git commit.

Seems like commit and merge --continue are largely equivalent in this context. Difference: the merge --continue variant does the extra check to confirm that a merge is in progress (and refuses to act if not), also it does not accept any additional arguments (like -m).

But regardless to these minor differences, calling either git commit or git merge --continue from the command-line (CLI) has the exact same effect - both bring up an editor to allow adjusting the commit-message! (Also, both commands will exit the "still merging" status.)

So, clearly, in the current context (of "Merge without commit") the two commands could be combined into a single one "COMMIT/CONTINUE" in the SourceGit UI. Also, any edits to the pre-filled commit-message should clearly be taken into account! (Otherwise, it would be like if the CLI command was opening an editor and then ignoring what's modified there...)

[goran-w]

TL;DR : The minimal implementation that would correctly match the command-line experience, is to still keep the CONTINUE button and the Commit (Edit) dropdown separate (as-is) but make CONTINUE take the edit commit-message into account (just like the dropdown Commit (Edit) does) - since that's what git merge --continue does on command-line.

[goran-w]

Guiding principle : There should not be a situation where the user is able to edit the commit-message, but those edits are discarded (without warning) when the user does Commit / Continue etc.

If edits would be discarded by all the available actions, then the edit boxes should be disabled / grayed-out. (Or, if only one/some of the available actions would discard the edits, then these should popup a warning, with a way to cancel and choose another action.)

[love-linger]

I don't think merging COMMIT and CONTINUE is a good solution. These two buttons are common behavior for merge/rebase/cherry-pick/revert commands. For example, for an edit operation in rebasing, the user can split the current commit into multiple commits and then continue.

[goran-w]

That's fair, but just to clarify further:

The Continue button is just bound to the `git merge/rebase/revert/cherry-pick --continue' command. The filled commit message will not be applied.

As I pointed out above, this implementation actually does NOT reflect what the underlying command does by default. (At least in the merge case.)

So, as mentioned above, the very minimal fix for this issue is to just make CONTINUE use the edited commit-message (as it should).

[love-linger]

So, as mentioned above, the very minimal fix for this issue is to just make CONTINUE use the edited commit-message (as it should).

Done. You can download the latest CI build from Github Action.