Add an option to disable SparkleShare's own conflict resolution

[colonelpanic8]

I would prefer it if Sparkleshare did not perform its own conflict resolution (the kind where it keeps copies of both files), and simply stop trying to sync if there is a conflict that is not automatically resolvable with git.

It would be great if there were a configuration option that would allow this behavior.

[hbons]

Why's this? :)

[colonelpanic8]

@hbons sorry, I'm not sure what you mean. I would just rather have control over my own git history, and I don't like that sparkleshare adds a totally new file that you must then manually merge back in to the main file.

[hbons]

Just wondering what your use case is. I decided to go this way to keep things simple, and keeping a history is less important.

[colonelpanic8]

Just wondering what your use case is. I decided to go this way to keep things simple, and keeping a history is less important.

My usecase for sparkleshare in general is saving org-mode which I view in emacs on multiple computers. Its much harder for me to manually merge when there are conflicts than it would be for me to use git conflict resolution. I really just want to use sparkleshare as an automatic, live, background sync, but for it to prompt me that there is a conflict when it encounters one and ALLOW ME to resolve it.

It would be really easy to allow this as a configuration option, would it not?

[colonelpanic8]

@hbons Are you really opposed to adding an option to disable this behavior?

[colonelpanic8]

@hbons The other problem with this approach is that it does not make it obvious when there is a serious merge conflict that needs manual intervention. It is extremely annoying that sparkleshare has this behavior to me, and I see almost no harm in making the change.

[hbons]

This will be difficult to add. I don't think this will be a very common use case to be worth the effort. You can always revert files from the history and take back what you need.

[colonelpanic8]

@hbons it would not be difficult to add at all. I've looked at the csharp code and all it would require is looking at a global config setting and simply refusing to do anything in the case of a conflict. This would allow the user to resolve the conflict in an appropriate way. I would do it myself but I don't really have a good csharp development environment set up.

[hbons]

It affects how the sync algorithm works and will add more edge cases for maintenance, so I'd rather not add it.

[falsifian]

FWIW, I also don't particularly like the way Sparkleshare handles conflicts, and would enable such an option if it were there. I won't re-open this since I'm a git power-user and I imagine this tool is meant to require less experience to use, but wanted to note @IvanMalison is not the only one.

Here's one thing that I'd consider almost as good as that option: saving three versions of the conflicting file: original, changed version A and changed version B. That way it's easy to use a diff tool to see what the conflicting changes were. With the current behaviour I feel like I'm guessing what the original version was.

[colonelpanic8]

I'm a git power-user and I imagine this tool is meant to require less experience to use, but wanted to note @IvanMalison is not the only one.

I seriously doubt that anyone that knows anything about git likes the current settings. I've looked at the code and I just don't think its fair to say that adding a setting would significantly complicate the code, as @hbons claims.

With the current behavior I feel like I'm guessing what the original version was.

Yep, and it also breaks history/blames and adds extra information to git history that is not needed.

[hbons]

I like the idea of keeping the original and both modified versions. This can be the new default behaviour.

[colonelpanic8]

I like the idea of keeping the original and both modified versions. This can be the new default behaviour.

How is this LESS complicated than just doing nothing which should very obviously ALSO be an available mode of operation?

[hbons]

This new behaviour is better regardless. I don't mind doing some work to get things to work better for everyone, but I don't like adding an edge case options that's hand for a handful of users, that's why.

[colonelpanic8]

@hbons

This new behaviour is better regardless.

Better than what this issue was originally made to request? I simply do not agree that that is the case.

Git is already very good at handling conflict resolution, and this method completely throws away all of the existing infrastructure (command line/tig/magit/source tree etc. etc.) that allow one to do side by side diffs of conflicting files, which is much easier to deal with than "here is one version of the file and here is another, work out for yourself which parts of each file you want to keep" in my opinion.

don't like adding an edge case options that's hand for a handful of users, that's why.

@hbons Why are you so sure that it's just a handful of users? I think you are making that assumption based on the fact that YOU (for reasons that are WAY beyond me) happen to prefer this method of conflict resolution.

I love sparkleshare and I use it to synchronize 4 different repositories, but this issue afflicts me so regularly that I am seriously considering forking or writing a new tool in a language that is familiar to me to do the same thing. I implore you to reconsider your position on this (namely simply accepting a pull request to ALLOW this behavior -- I am not even asking you to do the work) because this sort of forking is not the sort of thing that is generally good for a community. It is hard for me to take your stated reason for not wanting to allow this change (that it will increase complexity) seriously, when it literally amounts to adding a preference and a single conditional statement.

EDIT: I'll even volunteer to completely maintain the relevant part of the code path. How about this: let me do the work to show you how simple this change really will be. I seriously doubt that it will be very complicated.

[colonelpanic8]

You can always revert files from the history and take back what you need.

@hbons I just noticed this comment. It seems that you aren't properly understanding the case that is particularly bothersome to me. Sometimes I want to keep changes from BOTH versions of the file. With sparkleshares current behavior, how is one supposed to integrate changes from both versions of the file?

The easiest way to do this that I can think of (again with sparkle shares current behavior) is to use the diff tool to look at the differences, and then MANUALLY copy the portions from the conflicted file that must be kept. The otheralternative (which is what I actually do) is to do a hard git reset to before the git conflict occured, and manually trigger the same conflict that sparkleshare encountered, and then use git to resolve the changes.

Perhaps you aren't understanding the following aspect of the requested behavior: I am not asking that sparkleshare prompt the user with the conflict resolution, or really to do anything at all. I am just asking that it cowardly refuse to do anything at all. This is what it will naturally do if we simply refuse to resolve conflicts in the current code path, because it will simply LOOP over that code path until the conflicts are resolved.

As I've stated before all that needs to be done is:

• add a preference
• add a conditional to check the preference before taking the current conflict resolution code path

[katandtonic]

Just to reiterate @IvanMalison and @falsifian, I would also like this feature.

[aggsol]

Sparkleshare is not for the git-savvy user. I installed on many laymen computers with great success. The less options there are the less they are to fiddle with them around. Especially disabling sync can lead to great disaster. Also as Sparkleshare is still git-centric I see it using other backends soon (e.g. S3 or the like). I also like the idea of having common, theirs, mine files as most file type don't merge well with git anyway (e.g. spreadsheets). Just my two cents.

[hbons]

The new way of conflict resolution is now implemented in 8c8a5a4 (keeping both versions of the file, plus the original).

[colonelpanic8]

For anyone coming up against this issue, or just generally looking for a more power user friendly solution (ironic right?), here is what I've landed on:

I wrote a little wrapper:

https://github.com/ivanmalison/dotfiles/blob/3a0c142760a930fd41441a645d78ec2a83bf7811/dotfiles/lib/bin/git_sync_directory.sh#L8

around the incredibly simple:

https://github.com/simonthum/git-sync

git-sync itself handles the logic of

• committing
• fast forwarding
• doing automatic merges

While the wrapper handles tracking changes and triggering git sync both on an interval, and whenever it detects relevant changes. The wrapper script is intelligent about gitignores and is pretty robust.

The best part is that it is actually much more predictable than sparkleshare, and updates happen much more rapidly (sidenote is sparkleshare not using inotify? seems strange that a shell script would outperform a dedicated process written in a compiled language...)