Introduce a new event GitConflictAborted or fire GitConflictResolved when git merge conflict is aborted

[nsoufian]

Hello,

I have been using the git-conflict.nvim plugin and it has been a great addition to my development process. However, I have noticed a potential area for improvement concerning the management of aborted git merge conflicts.

Currently, the plugin fires a User autocommand GitConflictDetected when a conflict is detected, and another autocommand GitConflictResolved when it is resolved. This functionality is quite useful and allows users to set specific mappings or processes for these events.

However, there seems to be a gap when a merge conflict is aborted. When the conflict is aborted, no event is dispatched and previously loaded user settings (such as mappings) are not unloaded for the buffer. This can lead to unnecessary mappings and even lingering diagnostic information if the option is enabled, as the plugin uses these events internally.

To address this, I propose that we should fire the GitConflictResolved event when a merge conflict is aborted. This would naturally unload the associated settings and clear any lingering diagnostics. However, if this could potentially break compatibility, an alternative could be to introduce a new event like GitConflictAborted. This new event could be dispatched whenever a merge conflict is aborted, allowing users to handle this case separately if they desire.

I would be more than happy to contribute and submit a pull request to implement this feature. However, I may need some guidance or hints on where to start. Any assistance would be greatly appreciated.

Thank you for your time and consideration. I look forward to hearing your thoughts on this matter.

[akinsho]

Hi @nsoufian, the idea sounds good to me although I think one issue I'm not sure about/probably misunderstand is that I don't know how we would know

when a merge conflict is aborted.

What does aborted mean here? you mean they don't resolve it and they run git merge --abort or git rebase --abort or something? in which case probably the mass of the complexity will be figuring out if they did that? The way I implemented some things was by watching for certain changes in the .git directory. Maybe there is a similar change that would tell you this or maybe you already know what to look for? In either case if you know how you want to tackle it I'm definitely open to a PR but AFAIK I have no idea what abort even really means concretely i.e. what is it equivalent to in code/git dir/fs changes

[nsoufian]

Thank you for considering my suggestion.

What does aborted mean here?

by "aborted" I mean when a git operation such as git merge --abort or git rebase --abort is executed.

In terms of implementation, one way to detect if a merge or rebase has been aborted could be to look for changes in the .git directory. When a merge or rebase is in progress, Git creates a MERGE_HEAD or REBASE_HEAD file in the .git directory. If a merge or rebase is aborted, these files are removed.

So, one possible approach could be to monitor the .git directory for the removal of these files, which would indicate that a merge or rebase has been aborted.

I look forward to your thoughts and guidance on this matter.

[akinsho]

@nsoufian so this plugin already watches the .git directory and essentially anytime it changes (with several layers throttling) it tries to refresh the conflict markers.

git-conflict.nvim/lua/git-conflict.lua

Line 426 in 75e9056

local on_throttled_change = utils.throttle(1000, function(dir, err, change)

Technically it should already pickup if a git operation is aborted but obviously if it is done within the threshold for throttling it will be missed. I initially tried to make the watching not throttled but only listen for specific changes but that directory changes so often you'd really need to know precisely what watch for not to slow down someone computer.

I guess to do this you should first test what happens when git merge abort is run with the plugin. I'd expect things to disable but if not I'd add some logs to see whether the throttled function isn't run.

In which case the next step could be to actually refactor the watching to listen for specific changes i.e. the MERGE_HEAD changes and then only call fetch conflict in those cases and maybe pass the "reason" to the fetch_conflict function and use that to control which autocommand is sent. Although frankly I don't think a new autocommand is needed just higher fidelity for the existing ones