git-conflict.nvim icon indicating copy to clipboard operation
git-conflict.nvim copied to clipboard

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

Open nsoufian opened this issue 1 year ago • 3 comments

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.

nsoufian avatar May 16 '23 19:05 nsoufian