I’m Divyansh Khurana , and I have been working on a proposal to bring Automatic Conflict Resolution to Joplin.
Please give feedback if possible.
GSoC 2026 Proposal Draft – Idea 10_ Automatic Conflict Resolution (2).pdf (506.3 KB)
GSoC 2026 Proposal Draft – Idea 10_ Automatic Conflict Resolution (3).pdf (619.4 KB) (latest)
Hi @mrjo118, can you review this proposal if possible
Hi @laurent @CalebJohn , can you review this proposal if possible
Although the original proposal idea mentioned resolving conflicts automatically where possible (i.e. where there are no overlapping changes), I realised we should avoid auto merging conflicts silently, because it has the potential to corrupt binary data contained within notes. This is particularly a concern because we will likely be doing an encryped notes GSoC project in parallel to this, where auto merging conflicts for such notes could be a real risk.
Therefore all conflict resolution in the proposal should be assisted rather than automatic. But in cases where there are no overlapping lines, having a button to merge all non conflicting changes should enable resolving these type of conflicts with minimal effort.
Thanks. I will revise the proposal so resolution is assisted only. btw we can still use a three way model (base / local / remote) and classify non overlapping edits, but no silent merge into the note body. For those clean regions I will describe a single explicit action something like “Merge non conflicting changes” (with preview of it), not auto apply on sync. And, I will adjust the proposal so encrypted notes are explicitly out of scope for any automatic or silent byte level merge.
One thing I wanted to get right though :
Should I treat the rule as no persisted merge without a user action in the conflict UI?
btw we can still use a three way model (base / local / remote) and classify non overlapping edits
Yes it’s allowed, but not guaranteed to be available, as base version cannot be recorded for notes unchanged before code changes for this project are available to the user. So there must be 2 way merge as a fallback where 3 way is not possible
encrypted notes are explicitly out of scope for any automatic or silent byte level merge.
Encrypted notes should not have any special handling, as that creates a dependency to the other GSoC project. No fully automatic merge is enough to cater for them.
Should I treat the rule as no persisted merge without a user action in the conflict UI?
Correct. But don’t rely on the user being able to revert an automatic merge as a means to allow auto merge, as this adds complication to the solution. Just don’t auto merge in the first place, and always require user action to merge
Thanks, I will update the proposal accordingly
Hey @mrjo118 . I have updated the proposal accordingly and posted the latest doc. Please give it a final review before I can submit it.
Looks good now