Tower Git: Built‑In Resolver vs External Merge Tool – A Decision Guide

Decision: Which Merge Resolver Should Tower Use?

When a merge conflict appears in Tower, you can either rely on the app’s built‑in three‑pane resolver (Base / Local / Remote) or delegate the job to an external merge tool such as Kaleidoscope, Beyond Compare, or VS Code. The decision hinges on the type of files you edit, the complexity of conflicts, and team consistency.

Constraints to Consider

• File Types – Tower’s resolver handles plain‑text and code files but cannot diff binary assets (images, PDFs).
• Team Tooling – If your team already uses a specific merge tool for other Git operations, aligning Tower with that tool reduces context switching.
• Platform – On Windows, path quoting and tool CLI flags (e.g., --wait) must be correct; on macOS/Linux, forward slashes are default.
• Performance – For large diffs, external tools may offer faster rendering and more advanced algorithms.
• Consistency Across CLI and GUI – External tools invoked via git mergetool behave the same in Tower, ensuring a unified experience.

Supported Options in Tower

• Built‑In Three‑Pane Resolver (default)
• Pre‑Configured External Tools
  • Kaleidoscope
  • Beyond Compare
  • Araxis Merge
  • DeltaWalker
  • VS Code
• Custom CLI‑Launchable Tool (via Custom entry)

Comparison Table

Feature	Built‑In Resolver	External Tool
Context Inside Tower	Yes – commit list, file tree, diff view remain visible	No – launches separate window
Binary File Support	No	Depends on tool (most handle images, PDFs)
Three‑Way Diff Algorithm	Basic	Advanced (e.g., Myers, recursive)
Inline Editing	Yes – edit directly in the pane	Tool‑specific (e.g., VS Code editor)
Staging Resolved Hunk	Per‑hunk staging available	Whole file staged after tool exits
CLI Sync	Not applicable	Runs git mergetool, exits on success
Configuration Simplicity	None – default	Set via Preferences > Git Config > Merge Tool
Risk of Premature Commit	Low – Tower waits for user action	High if tool’s CLI lacks --wait flag

Trade‑Offs Explained

1. Convenience vs. Power
   Built‑In resolver keeps everything inside Tower, ideal for quick textual conflicts. External tools bring richer diffing, especially for binary assets, at the cost of leaving the app.
2. Consistency Across Environments
   If you commit .gitconfig with merge.tool set, both Tower and command‑line users will use the same tool. The built‑In resolver cannot be synchronized this way.
3. Team Standards
   When a team standardizes on a particular tool (e.g., Kaleidoscope for image diffs), configuring it globally in Tower ensures every member sees the same workflow.
4. Risk of Stale Backups
   External tools often create .orig backups. Tower respects mergetool.keepBackup; if unset, old backups can clutter the repo.

Concrete Implementation: Using VS Code as the Default Merge Tool

Below is a step‑by‑step example that works on macOS, Linux, and Windows (adjust paths accordingly).

1. Open Tower Preferences

   Navigate to Preferences > Git Config > Merge Tool and select Custom.

2. Configure the CLI Command

   Enter the following command, replacing $MERGED with the file path that Git passes to the tool:

   code --wait "$MERGED"
   

   On Windows, use forward slashes and escape spaces:

   code --wait "%MERGED%"
   

3. Verify Global Git Setting

   Open a terminal and run:

   git config --global merge.tool
   # Expected output: code
   

4. Create a Conflict for Validation

   In a test repository:

   git init test-merge
   cd test-merge
   
   echo 'base' > file.txt
   git add file.txt
   git commit -m 'base'
   
   git checkout -b feature-a
   
   echo 'feature-a' > file.txt
   git commit -am 'feature a'
   
   git checkout main
   
   git checkout -b feature-b
   
   echo 'feature-b' > file.txt
   git commit -am 'feature b'
   
   git merge feature-a   # conflict occurs
   

5. Trigger Merge in Tower

   Open the repo in Tower, click Merge on feature-a, and observe that VS Code launches.

6. Resolve Conflict in VS Code

   Make changes, save the file, and close VS Code. Tower will detect the tool’s exit code 0 and automatically stage the resolved file.

7. Confirm Resolution

   In the terminal, run:

   git status
   # Should show no conflicts and the file staged
   
   git diff --cached
   # Should show no conflict markers
   

8. Check for Backups (Optional)

   If you want to ensure no .orig files remain, list them:

   find . -name '*.orig'
   # Should return nothing if mergetool.keepBackup is false
   

Practical Validation Checklist

• Does Tower launch the chosen tool when a conflict is detected?
• Does the tool exit with code 0 when you close it after editing?
• Is the resolved file staged automatically in Tower?
• Are there no leftover .orig backup files unless you intentionally keep them?
• Does git status report a clean working tree after resolution?

Limitations

• The built‑In resolver cannot handle binary files; you must rely on an external tool for those.
• On Windows, incorrect quoting or missing --wait may cause Tower to proceed before resolution is complete.
• Tower’s preference for resolver type is global; different team members may see different UIs unless the environment is standardized.

Conclusion

Choose the built‑In resolver for quick, text‑only conflicts where staying inside Tower is a priority. Opt for an external tool when you need advanced diffing, binary support, or team‑wide consistency. The validation steps above ensure your configuration behaves as expected and prevents accidental commits or stale backups.