Skip to content

conflicts: Use `NewPath` for most of conflict resolution

Karthik Nayak requested to merge 5911-resolveconflicts-returning-13-retrieving-object-object-not-found into master

The ResolveConflicts RPC allows clients to resolve conflicts which occur during a merge by providing resolutions which can fix those conflicts.

The clients provide a set of resolutions, each resolution contains the following fields

  1. OldPath: Which is the path of the file pertaining to the ours commit.
  2. NewPath: Which is the path of the file pertaining to the theirs commit.
  3. Sections: Which is a set of choices, around which side of the conflict should be picked.
  4. Content: If set, instead of resolving the conflicts in a file, we just overwrite the file with this new content.

For files which are being moved (renamed) in the their commit. e.g.

  • Base commit: path => "foo"; content => "apple"
  • Ours commit: path => "foo"; content => "banana"
  • Theirs commit: path => "subdir/foo"; content => "mango"

the RPC would fail, this is because conflict resolution contains multiple steps, some of which involve:

  1. Reading and parsing the new conflicted file
  2. Reading and parsing the old file to ensure we carry over newline info.

Currently, we use resolution.OldPath for both these steps and this is an issue as you can see with the example shown above. This MR fixes this. But it might also be the case that we need to fix what data rails sends.

The usage of resolution.OldPath is probably because in most cases the 'ours' and 'theirs' commit have the same file path and this works out. But this generalization is wrong.

Closes #5911 (closed)

Merge request reports