2.2Pulling your team's work

How incoming changes are classified, what the pull card is telling you, and why your local edits are never overwritten.

Section 2 of 7 in this chapter

The left panel is your team's side of the project. The header shows which branch you are on and when the app last synced, with a refresh button beside it. Below that sits the incoming card, and below that the commit history.

Reading the incoming card

The card summarizes what is waiting — "3 files to pull, 2 outdated, 1 conflict" — and expands into the list. Three things can be true of an incoming file:

  • Outdated — a teammate committed a newer version and your copy is untouched. Pulling replaces it. This is the ordinary case and it needs no thought from you.
  • Conflict — a teammate committed a newer version *and* you have also changed the file locally. Pulling will not overwrite you. The file is held back until you decide.
  • Removed — the file was deleted upstream. It is deleted locally only if your copy is byte-identical to the committed one; if you had changed it, it stays.
                      teammate pushes a new version
                                   │
                     ┌─────────────┴─────────────┐
                     │                           │
          you changed it too              you didn't touch it
                     │                           │
                     ▼                           ▼
                 CONFLICT                     OUTDATED
          held back, nothing              pull replaces it
          on disk is touched                  silently
Figure 2-2. How a file arrives at each of the three incoming states.

Resolving a conflict

Because the files are binary, resolving means choosing, and the app gives you both options plainly: keep yours and push it over the top, or discard yours and take theirs. There is no third answer and no tool that can invent one.

The way to have fewer of these is not a better conflict view — it is locking, which is the next section.

Why syncs stay fast on huge projects

A naive sync hashes every file in the project every time, which on a hundred-thousand-file World Partition project is minutes of disk churn before anything useful happens.

Instead the app keeps an on-disk hash cache and watches the filesystem while it is running, so a routine sync costs roughly what actually changed rather than what the project contains. Reopening the app the next morning does not re-hash the world; it asks the operating system what moved while it was away and picks up from there.

Was this helpful?

Back to top