When autoresolve conflict fails...

[brenthuisman]

... 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]

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]

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]

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:

gin-cli/git/annex.go

Lines 1092 to 1107 in ed6f87f

	func checkMergeErrors(stdout, stderr string) error {
	messages := strings.ToLower(stdout + stderr)
	if strings.Contains(messages, "would be overwritten by merge") {
	// Untracked local file conflicts with file being pulled
	return fmt.Errorf("local modified or untracked files would be overwritten by download:\n %s", strings.Join(parseFilesOverwrite(messages), ", "))
	} else if strings.Contains(messages, "unresolved conflict") {
	// Merge conflict in git files
	return fmt.Errorf("files changed locally and remotely and cannot be automatically merged (merge conflict):\n %s", strings.Join(parseFilesConflict(messages), ", "))
	// abort merge
	} else if strings.Contains(messages, "merge conflict was automatically resolved") {
	// Merge conflict in annex files (automatically resolved by keeping both copies)
	return fmt.Errorf("files changed locally and remotely and the conflict was automatically resolved; you may want to examine the result")
	// TODO: This should probably instead become a warning or notice, instead of a full error
	}
	return nil
	}

and then the git merge --abort happens here:

gin-cli/git/annex.go

Line 170 in ed6f87f

mergeAbort() // abort a potential failed merge attempt

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