feat: add 'copier adopt' command for adopting templates in existing projects

[ichoosetoaccept]

Summary

This PR adds a new copier adopt subcommand that allows users to adopt a template for an existing project that was not originally created with Copier.

Closes #2486

Motivation

Many users have existing projects they want to bring under Copier management. Currently, the only option is copier copy --overwrite, which destroys existing customizations. The adopt command provides a safer alternative by merging template files with existing files using conflict markers.

What it does

Unlike copier copy, the adopt command:

• Creates new files from the template (files that don't exist in the project)
• Skips identical files (no changes needed)
• Merges differing files with git-style conflict markers (<<<<<<< existing / >>>>>>> template)
• Writes a valid .copier-answers.yml for future copier update calls
• Skips tasks by default since conflicts need resolution first (with a helpful message)
• Handles binary files by creating .rej files instead of corrupting them with conflict markers

Usage

copier adopt <template_src> [destination_path]

Options

• --conflict {rej,inline} - Behavior on conflict (default: inline)
  • inline: Add git-style conflict markers to the file
  • rej: Create a .rej file with the template version
• --defaults - Use default answers to questions

Example workflow

# Adopt a template for an existing project
copier adopt gh:org/template ./my-project

# Review and resolve conflicts
git diff
# ... edit files to resolve conflicts ...

# Run template tasks manually
uv sync  # or whatever tasks the template defines

# Commit the adoption
git add -A
git commit -m "chore: adopt org/template"

# Future updates now work with proper 3-way merge!
copier update

Implementation

The implementation:

1. Renders the template into a temporary directory using the existing run_copy machinery
2. Iterates through rendered files and compares with the destination
3. Uses git merge-file with an empty base for text files (creates conflict markers)
4. Creates .rej files for binary files (detected by null bytes in content)
5. Writes .copier-answers.yml directly (not from a template source)

Tests

Added 13 comprehensive tests covering:

• Core functionality (create, skip, merge, answers file generation)
• CLI interface
• Both conflict modes (inline and rej)
• Binary file handling (uses .rej to avoid corruption)
• Exclude patterns
• Non-git destination projects
• Deep nested directory structures
• Templates with _subdirectory
• Pretend mode
• Enabling future updates

All existing tests continue to pass (215 total).

Checklist

• Code follows project style (ruff, editorconfig)
• Tests added and passing
• Pre-commit hooks pass
• Conventional commit message

[sisp]

Thanks for contributing this valuable feature to Copier, @ichoosetoaccept! 🙇

I think this is a great idea. Before reviewing the changes in detail, a few rather general remarks:

• How about naming the command onboard? For example, Renovate creates onboarding PRs, it sounds like a more familiar term in a somewhat similar context to me.
• Once #2376 lands, .rej files will be dropped. I imagine nobody uses .rej files anymore because we have had more familiar inline conflict markers for quite a long time and they have also been the default setting for a while. How about omitting .rej files support for this command right from the beginning? This would reduce complexity and avoid code that will likely be removed in the (hopefully) near future again.
• Long-term, I think we'll want more flags like --data. I assume you didn't add them in this PR to keep the scope of the PR manageable. We can add more useful flags in follow-up PRs.