能否限制git rerere仅作用于指定目录？临时启用方案咨询

Great question—rerere is a clever tool, and it makes total sense to want control over where it’s active instead of locking yourself into a global on/off switch. Let’s break down answers to all your concerns:

1. Enable Rerere Only for Specific Repositories #

You absolutely don’t have to use global settings! Git lets you configure rerere at the repository level, which is perfect for your use case.

To turn on rerere for just your current repo:

git config rerere.enabled true

This setting overrides any global rerere configuration, so other repositories will stick to their default (disabled, unless you’ve explicitly turned global on). To double-check the setting for your repo, run:

git config --get rerere.enabled

If you ever want to disable it for this repo later, just run:

git config rerere.enabled false

Storing Rerere Cache Inside the Repository #

You mentioned wanting to use a script to store the rerere cache within the repo itself. By default, rerere uses a global cache at ~/.git-rerere-cache, but you can override this for individual repos:

git config rerere.dir .git/rerere-cache

This will save all conflict resolution history for the repo in .git/rerere-cache. If you want to track this cache in version control (note: this is non-standard, so test it carefully if collaborating), you’ll need to adjust your .gitignore to exclude most of .git/ but allow this directory, or use your script to sync it to a tracked folder. Just keep in mind that shared cache files might create conflicts if multiple people are using rerere on the same repo.

2. Temporary Enable/Disable for Targeted Workflows #

If for some reason per-repo config isn’t feasible (though it’s the cleanest solution), you can toggle rerere on and off temporarily during your workflow. Here’s a safe way to do it without messing up your existing settings:

# Save your current rerere setting to restore later
OLD_RERERE=$(git config --get rerere.enabled)

# Turn on rerere for this workflow
git config rerere.enabled true

# Run your conflict-prone operation (merge, rebase, cherry-pick, etc.)
git merge feature-branch
# Or git rebase main

# Restore your original rerere setting
git config rerere.enabled "$OLD_RERERE"

If you didn’t have a prior setting (i.e., OLD_RERERE is empty), this will leave rerere unset (which defaults to disabled, unless your global config says otherwise).

Key Workflow Steps #

• Before executing an operation that might trigger conflicts, enable rerere to let it track your resolution.
• After resolving conflicts (or letting rerere auto-apply a past solution) and completing the operation (e.g., git commit or git rebase --continue), restore your original rerere setting to limit its scope.

Quick Tips #

• Repository-level config always takes priority over global config, so even if global rerere is disabled, a repo with rerere.enabled true will still use the feature.
• rerere only auto-resolves conflicts it’s seen before—you’ll need to manually resolve a conflict the first time, but it’ll remember your fix for future identical conflicts.

内容的提问来源于stack exchange，提问作者Adrian