Architecture Note: Tower Git Merge Conflict Resolver Design

Problem

After a git pull or git merge you see conflicted files in Tower’s status view. Resolving them manually with a text editor is error‑prone and hides the relationship between the three versions involved.

Useful Takeaway

Tower’s built‑in three‑way merge conflict resolver lets you view base, local, and remote changes side‑by‑side, accept or edit chunks, and preview the resulting commit—all while keeping file contents on your local machine.

Requirements

• Repository opened in Tower (any local working copy).
• Conflict detected by Tower’s file status view (files marked with both \(U\) and \(M\) icons).
• User invokes Resolve Conflicts from the context menu or toolbar.
• Tower version ≥ 3.0 (the visual resolver was introduced in this release).

Smallest Suitable Design

The resolver consists of three panes:

1. Base – the common ancestor version.
2. Local – your current branch’s version.
3. Remote – the incoming version from the merged branch.

Each pane shows the file content with conflicting regions highlighted. The user can:

• Click a region to choose Local, Remote, or Base.
• Edit the region directly in the merged preview pane.
• Accept all non‑conflicting changes automatically.

When satisfied, the user clicks Apply; Tower writes the merged content to the working copy and stages the file.

Trust/Data Boundaries

All file data remains in the local working copy. Tower does not transmit file contents to external servers unless the user has explicitly enabled optional crash‑reporting or telemetry (Preferences → Advanced). Network traffic during conflict resolution is limited to:

• License validation (if applicable).
• Telemetry opt‑in endpoints, which can be disabled.

Operational Checks

• Automatic detection of conflict markers (\(<<<<<<<\), \(=======\), \(>>>>>>>\)).
• Optional integration with local lint/build tools: after applying a resolution, Tower can run a configured command (e.g., npm run lint) and show the result in the preview pane.
• Preview of the resulting merge commit message before finalizing.

Failure Modes

• Large files (LFS): rendering the three panes may become sluggish; performance depends on disk I/O and available RAM.
• Binary files or submodule updates: the visual resolver cannot display a meaningful diff; Tower falls back to an external merge tool or requires manual resolution.
• Version < 3.0: the feature is unavailable; Tower uses the configured external merge tool.

Conditions That Would Change the Design

• If a significant portion of users regularly resolve binary conflicts, the design might incorporate a binary‑aware diff view or launch an external diff tool directly from the resolver UI.
• If telemetry opt‑in becomes mandatory for licensing, the trust boundary would need to be re‑evaluated and possibly encrypted transmission added.
• Performance improvements in asynchronous UI frameworks could allow the resolver to handle very large text files without blocking the main thread.

Concrete Example Workflow

1. Open a repository in Tower that has a conflict in src/app.js after a git merge feature/login.
2. In the file status view, right‑click src/app.js → Resolve Conflicts.
3. Three panes appear: Base (commit abc123), Local (your main branch), Remote (incoming feature/login).
4. Select a conflicting chunk; click the Remote button to accept the incoming change, or edit the text directly in the preview pane.
5. After all chunks are resolved, press Apply. Tower stages the file and updates the status view to show src/app.js as modified (no longer conflicted).
6. Optionally, click the Preview button to see the commit message and diff before committing.

Verification Steps

• Confirm Tower version: Help → About shows version ≥ 3.0.
• Open a known conflicted repository, invoke Resolve Conflicts, and verify the three‑pane UI appears.
• Disable telemetry (Preferences → Advanced → Telemetry) and monitor with a local proxy (e.g., Wireshark or mitmproxy) to ensure no file‑content traffic leaves the machine during resolution.
• After applying a resolution, run git status in Tower’s embedded terminal; conflicted files should be absent.

Limitations

• Visual resolver does not support binary files or submodule tree conflicts.
• Performance may degrade with very large text files (> 10 MB) or LFS objects.
• Only available in Tower ≥ 3.0; older versions require external merge tool configuration.

Rollback (Abort Merge)

If you decide not to keep the merge after starting conflict resolution, you can abort the operation:

1. In Tower’s repository view, click the Abort Merge button (appears when a merge is in progress).
2. Alternatively, run git merge --abort in the embedded terminal.
3. This returns the working copy to the pre‑merge state, leaving any conflict markers removed.