search

G-Node / gin-cli

Command line client for GIN
https://gin.g-node.org
Other
12 stars 6 forks source link

When autoresolve conflict fails... #297

Open brenthuisman opened 3 years ago

brenthuisman commented 3 years ago

... there seems to be no indicator of how to proceed. I think the local copy is kept, and the remote is not retrieved. Maybe some options could be given: keep local, overwrite with remote, rename remote, etc.

achilleas-k commented 3 years ago

The Usage Tutorial for the GIN CLI on GIN has a section on Handling conflicts which covers this scenario. The best course of action (in my opinion, anyway) is to rename the local file, download the remote file, and then resolve the conflict either by discarding the remote, discarding the local, or merging their content by hand somehow.

This is only required for git files. Conflicts in annexed files are handled by git annex directly. The problem with the scenario here (git file conflicts) is that there's no straightforward or safe way to rename the remote file or overwrite the local one. I think it's safer for the user to be in control of the conflict resolution by making the changes to the local files themselves.

It's probably best to add instructions to the command output about how to resolve the issue. Please keep this issue open so we can track the change.

brenthuisman commented 3 years ago

Is the tutorial/help on g-node a superset of the wiki attached to this repo? I forgot at what point, but there was some info in the wiki that I could not find on g-node.

In any case, I had the error on an annexed file. I suppose annex did have a problem autoresolving. I think git annex has a prompt for (similar to what I propose) to handle a conflict that it can't autoresolve, but this might not be then forwarded to gin. I resolved it by deleting the local repo and checkout out afresh, so I can't double check this. Do you know how gin handles this?

So yes, if you don't want to add prompts to gin, a hint on how to handle the conflict (even if it's a link to the tutorial) would be great, for both files in git and git annex.

achilleas-k commented 3 years ago

Yes, the information on G-Node is a superset of the wiki on this repository, except for some developer notes that aren't transferred. I've noticed now that the links in the README of this repository are outdated. I will fix them immediately.

In any case, I had the error on an annexed file. I suppose annex did have a problem autoresolving.

Interesting. Git annex should keep both files and append unique identifiers to each filename when there's a conflict like that.

Do you know how gin handles this?

When a merge conflict occurs, GIN CLI tries to detect what kind it is by checking the git (annex) command output, in order to present the appropriate message to the user and then does a git merge --abort. If you'd like to see the merge conflict detection code, it's here: https://github.com/G-Node/gin-cli/blob/ed6f87f56f1840075d7276557c2d6457ddb6b1f0/git/annex.go#L1092-L1107 and then the git merge --abort happens here: https://github.com/G-Node/gin-cli/blob/ed6f87f56f1840075d7276557c2d6457ddb6b1f0/git/annex.go#L170

The abort of the merge is to avoid having partially merged files in the working tree.