I’m not sure if the below-described feature is already available or has already been discussed (the only similar thing I found was Unison as optional syncing backend). So, flame away if I’m trying to resurrect a dead horse.
I want to synchronize files across devices (like most people here). But, for some files I want to specify the merging strategy myself. The way I think about this being implemented is something like how git does it with git bisect run (Git - git-bisect Documentation): You specify a script to run and if exit 0 then no conflict; if exit 1 (or greater) then conflict.
I’m thinking that syncthing could either be configured either with:
a user-provided mapping of file extension to “merge script”/“merge executable” optionally provided at start-up (optionally meaning that it’s not required if the user has no ad-hoc merge logic they want to run for any specific files - they don’t want to use this feature I’m describing)
an optional user-provided wrapper script which receives the relevant file’s information and the user’s script can decide (based on path, extension, size, header, etc.) whether to default to syncthing’s merging strategy or use a user-specified one.
Does this support exist in syncthing? If not, would such support be considered for addition? Unfortunately, I can’t commit to implementing myself. But, would a PR be accepted were it to be implemented and/or would maintainers consider implementing such a feature themselves?
it sounds like you mean “custom conflict resolution tool”
Thanks for your response! You’re exactly right. I conflated “synchronization” with “conflict resolution”.
Alright, it seems that no effort is being made to prioritize this in syncthing, itself (such that users are implementing ad-hoc solutions). Is this true? Please note that this question is not intended to denigrate/attack - only to clarify the current status of this feature.
Would a PR (change set) which implements something like what I’m describing in 1. or 2., above, be accepted? And, if so, which of those 2 alternatives is preferable? I’m partial to 2. since it’s a bit more flexible and doesn’t depend on extensions (shortcomings: I would need to restart syncthing with any changes to which extenions are handled (or how), I wouldn’t be able to use anything else like path information, I can already predicate on extensions using 1., etc.).
No effort that I’m aware of, no. I see no in-principle blockers against accepting a PR they does 2 above, it would be analogous to our external versioning functionality. Indeed very similar since it would essentially be a command that takes two parameters (old file and conflicted one) and is responsible for creating the resulting new file.
I think any mapping of extensions to tools etc belongs as the responsibility of this external script.