Skip to content
NOEMATA

Resolving conflicts

A checkout of an fs.remote deployment is a project directory that you publish from and fetch to. Publish and fetch compare each path in three versions: disk (the file on your filesystem now), the tracked base (the version this checkout last fetched or published, recorded as one content hash per path in .data/tracked.json), and the published revision (the version the deployment serves now). Usually only one of disk and the published revision differs from the base. A change on disk is then yours to publish, and a change in the deployment is fetched. A conflict is a path that changed both on disk and in the deployment since the base. Noemata does not choose a version for a conflict; you resolve it.

The kinds

Both edited. The same path changed on disk and in the deployment since the last fetch or publish, to different content. This usually happens when you edit a frame locally and someone edits the same frame in the app.

Differs on first run. .data/tracked.json has no entry for the path yet, for example in a fresh clone or after .data/ was deleted, and disk and the deployment have different content for the path. Without a base, Noemata cannot tell which version is newer.

Edited locally, deleted remotely. You changed the path since the last fetch or publish, and it has since been deleted from the deployment.

Deleted locally, edited remotely. You deleted the path on disk, but it changed in the deployment since the last fetch or publish.

Where conflicts show up

  • noemata publish publishes only what changed on disk since the last fetch or publish; a disk copy older than the published file is left alone.
  • noemata fetch (fs.remote) writes the deployment’s changes to the files you haven’t changed, and keeps your unpublished changes, including the deletion of a published file. --dry-run reports the conflicts without writing anything.
  • A local server that drafts on disk writes each new revision to the files you haven’t changed, keeps your version of a conflicting file, and logs the conflict.

Resolving

Each conflicting path is resolved to one of two versions:

  • Keep mine (ours): your version stays, and the deployment’s version becomes its new base, so the next publish publishes your version.
  • Take theirs (theirs): the deployment’s version replaces yours on disk. When the deployment deleted the path, your copy is deleted.

How to choose:

  • In a terminal, noemata resolve, noemata publish and noemata fetch ask about each conflicting path, and can show the difference or leave the path for later.
  • noemata resolve <path>... --ours (or --theirs) resolves the conflicts at the matching paths without asking. A path can be a glob pattern, such as '@frames/services/**'.
  • noemata resolve --discard <path>... discards your changes to the matching paths, whether or not they conflict.
  • --accept-ours or --accept-theirs on publish and fetch resolves every conflict of that run with one version, and lists each conflicting path with the version used.

Outside a terminal, and without --accept-ours or --accept-theirs, publish and fetch refuse to run when there are conflicts, and list the paths. When a file changes while its path is being resolved, the path keeps your local version and is reported.