Add option for autocontinue after git rerere resolved conflicts

[vovodroid]

Feature description

It would be good to continue merge when git rerere successfully resolved recorded conflicts. For instance like was proposed here https://stackoverflow.com/questions/18003917/git-rerere-does-not-auto-commit-autoupdated-merge-resolutions/27513648#27513648

Environment

• Git Extensions 4.2.0.17591
• Build bf814d4f1c6f178eacef38d592b700f9f2519dcb
• Git 2.42.0.windows.2
• Microsoft Windows NT 10.0.19044.0
• .NET 6.0.25
• DPI 96dpi (no scaling)
• Portable: False
• Microsoft.WindowsDesktop.App Versions

    Microsoft.WindowsDesktop.App 6.0.25 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

[RussKie]

Would you like to work on this?

[mstv]

Add option for autocontinue

The existing option should suffice. Though we "just" need to detect that the conflicts have been resolved and to continue.

[vovodroid]

Would you like to work on this? we "just" need to detect that the conflicts have been resolved and to continue.

Well, generally I can, but I'm unfamiliar with git command line and with GitExtension code. But with a help I can try to do this.

Could you refer me to some point in the source code to start from?

[mstv]

FormResolveConflicts._thereWhereMergeConflicts might be the key. I have found it by searching for the option AppSettings.DontConfirmCommitAfterConflictsResolved.

[vovodroid]

FormResolveConflicts._thereWhereMergeConflicts might be the key.

Ok, I'll try to check what's happen. Thanks.

[vovodroid]

I'm doing test rebase. After closing this window

I get assert

with empty commandOutput. Could it be origin for not continuation of rebase?

[mstv]

In this callstack, this is a false error IIUIC. We should turn line 180 of GetRevision(commitHash, ...) into

            if (commandOutput.Length == 0 || !TryParseRevision(commandOutput, out GitRevision? revision))

(Sorry, this is a regression from a recent refactoring in a different code path.)

[vovodroid]

Ok, I guess I found the reason, nothing complicated, but I need a hint how to fix this.

First, FormResolveConflicts._thereWhereMergeConflicts is not involved in scenario in question.

After rebasing EnableButtons() is called:

And code inside is aware that there are no conflicts and we are inside of rebasing:

So "Continue rebase" button is displayed:

So all we need is somehow proceed to

whether directly or by emulating click on the button, while leaving OkClick. Or run loop inside of OkClick.

What would be preferred way?

[vovodroid]

Also we need to close this dialog

as well, if we want the whole rebasing process to be done without unnecessary interactions.

[vovodroid]

And skip this one (is it Git's own dialog?)

[mstv]

button.PerformClick() or the like is used in the code base. If it is applicable here, it is worth a try.

Yes, it is git who opens the editor for the commit message after resolving conflicts because there might be something to add to the commit message.

If have never seen a popup "Current branch a is up to date" - whatever "Current branch a" means, which might be the cause why I have never seen it.

---

Could you add your subscription to contributors.txt in a separate PR, please?

[vovodroid]

Could you add your subscription to contributors.txt in a separate PR, please?

I still didn't contribute anything))). Should this list contain real name and email?

Looking at this

screenshot I thought that probably all this issue should be considered as Git bug. Git is asked to perform non-interactive rebase preserving merge, but despite applying recorded resolution it still thinks that there is error, return exit code 1, preventing Gitextension to close this window even with "Keep dialog" unchecked, and showing "Continue rebase" as if there was real conflict resolved by user. And also Git opens editor with commit log, despite no "interactive rebase" is turned on.

I suggest that in such case Git should to what it was asked to do - full rebase without user intervention. Is it worth to open bug in Git repository?

[vovodroid]

We should turn line 180 of GetRevision(commitHash, ...) into

@mstv, open PR or you'll do?

[mstv]

We should turn line 180 of GetRevision(commitHash, ...) into

I have tried to do so and to setup a testcase.

Does the requested revision exist? If not, the exit code of the git command should be 128 (at least not 0) and an ExternalOperationException would be thrown. If yes, then the output of the git command should not be empty. If the exit code is 0 and the output is empty, it might be a race condition caused by calling RunDetached and reading the output without awaiting the process exit.

[vovodroid]

Does the requested revision exist?

Sure.

[mstv]

Does the requested revision exist?

Sure.

Then I guess process.WaitForExit() or the like is missing after RunDetached.

[gerhardol]

I suggest that in such case Git should to what it was asked to do - full rebase without user intervention. Is it worth to open bug in Git repository?

Git tries to be nice to allow changes to the commit messages after conflicts as the rebase did not go without manual tweaks. So you would request a change of behavior which I doubt will be granted.

[vovodroid]

Git tries to be nice to allow changes to the commit messages after conflicts as the rebase did not go without manual tweaks.

But my complaint is about case when conflict was already resolved in the past, and now is just applied by rerere option.

you would request a change of behavior

I will)))

[vovodroid]

Well, I implemented very dirty solution for continue rebasing https://github.com/vovodroid/gitextensions/commit/436d25e01987c29afe61d6997045b46fd89da46d

It can close git cmd window and continue rebasing if it suggests that no error found (though it could now know this for sure).

I'll open bug in Git repository, let's see what will be reaction.

[vbjay]

Their point is not that the conflict was resolved but that a conflict occured. Doubtful you will convince git to alter the behavior. Rerere just played your resolution over the existing conflict. Git is still giving you a chance to tweak the commit because the conflict existed. Highly doubt they will change it.

[vovodroid]

Git is still giving you a chance to tweak the commit because the conflict existed.

Git can at least add option to rerere or command line to skip if user wish.

[vovodroid]

Surprisingly Git has no bug reporting system, I've sent report to their bug mailing list, no answer so far.

So I can make PR with addition of configuration option to turn on this auto continue mechanism. Or "Interactive rebase" option could be used.