Add new 'Sync Method' setting in place of mergeOnPull and new experimental obsidian-sync compatible sync method.
#165
Conversation
- Also adds support for new 'reset' method for compatibility with obsidian sync. - Obsoletes `mergeOnPull` setting to instead use `syncMethod = 'merge'`.
|
|
||
| } | ||
| const pullResult = await this.git.pull([this.plugin.settings.mergeOnPull ? '--no-rebase' : '--rebase'], |
There was a problem hiding this comment.
Previously, we were using git pull to fetch and merge changes. git pull is a shorthand for git fetch followed by either git rebase FETCH_HEAD or git merge FETCH_HEAD (https://git-scm.com/docs/git-pull/2.1.4#_description).
In the new changes on the right, you'll see that we're intentionally git fetch-ing separately from git merge or git rebase, but otherwise these are largely functionally the same.
src/settings.ts
Outdated
| if (plugin.settings.syncMethod) { | ||
| dropdown.setValue(plugin.settings.syncMethod) | ||
| } else { | ||
| dropdown.setValue('merge') |
There was a problem hiding this comment.
Because of the default value of syncMethod it should always be non undefined.
|
LGTM now. Thanks for the (I think) great idea of solving race conditions with other sync services. |
|
Awesome -- thanks for merging. Just btw, I'd been meaning to look into your comment "I noticed that files edited on another device are always staged", but haven't yet found the time and intend to have a closer look sometime over the next few days. |
|
Oh, nevermind, I see that you fixed that in f60f95c; thanks! |
|
Yeah I'm still unsure, but I think just unstaging all is fine. |
I use both obsidian-sync and obsidian-git so I can have both live updates & mobile support (via obsidian-sync) while also having change-by-change history (via obsidian-git). While far from home over the holidays with my work laptop, I encountered more than a few merge conflicts due to a race condition in which my laptop at home dutifully received changes via obsidian-sync, committed them, and then while it attempted to push those changes, it discovered that my work laptop had already committed changes and was thus in a conflict.
What this does is add a third method for handling sync (in addition to the existing
rebaseandmergemethods) that just lazily updates the currentHEADto match the sha of any fetched remote data without updating the local filesystem. That might seem surprising at first glance, but while using obsidian-sync, this works perfectly well due to obsidian-sync itself updating your local filesystem automatically as changes are discovered -- almost universally long before obsidian-git has even had a chance to discover that those changes exist on the remote. Additionally, if we keep obsidian-git out of that process, it can perform its normal commit/push processes for keeping an accurate historical record of changes to your notes without the possibility of getting trapped in a conflict.This also refactors how we indicate to obsidian-git which sync method to use. Before this change, there was a setting named
mergeOnPullthat is eithertrue(indicating that we should merge fetched changes) orfalse(indicating that we should rebase atop fetched changes). After this change, there is now a setting namedsyncMethodthat can be set to one of three values:merge,rebase, orreset(this is the new obsidian-sync compatible option). Settings will be automatically migrated forward at plugin load-time.I've been using this successfully for a week or so now, but it's important for me to say that although I've tested this pretty thoroughly with the new
resetmethod and spot-checkedmergeandrebase, it would be best if somebody who uses the more-normal sync methods gave this a shot, too, before merging.