Introduction

Git lets you override configuration values for a single command by passing -c key=value on the command line. This is useful when you want temporary behavior changes without editing .gitconfig, repository config, or system-wide settings.

Use -c for Temporary Overrides

The basic form is:

git -c key=value <command>

For example, you can force a one-off commit identity without changing your saved configuration:

git -c user.name="Release Bot" \
    -c user.email="[email protected]" \
    commit -m "Release build"

Those values apply only to that Git invocation. They do not permanently modify global or repository config files.

That makes -c ideal for automation, CI jobs, experiments, or edge cases where you need different behavior for exactly one command.

Practical Examples

You can override editor selection:

git -c core.editor=nano commit

You can force colored output in a specific context:

git -c color.ui=always log --oneline

You can change HTTP behavior or certificate checks for one network operation, though security-sensitive overrides should be used with caution:

git -c http.sslVerify=false clone https://example.com/repo.git

Multiple -c flags may be supplied, and Git evaluates them as high-precedence configuration for that process.

Precedence and Scope

Git configuration normally comes from several places:

• system config
• global user config
• repository local config
• command-line overrides

A -c value sits above the usual file-based configuration for the current invocation. That is why it is so convenient for short-lived changes.

However, the override is still only configuration. It does not rewrite history, change repository state by itself, or bypass the semantics of the command you are running. It simply changes how Git behaves while executing that one command.

When to Use This Instead of git config

Use git config when the setting should persist. Use git -c when the setting is intentionally temporary.

For example:

• CI pipelines often use -c user.name=... and -c user.email=...
• support engineers may temporarily adjust tracing or network behavior
• scripts can stay self-contained without mutating the caller's config files

That last point is important. A script that edits a developer's global Git config is much riskier than a script that supplies temporary overrides inline.

A Few Caveats

Not every configuration idea belongs on the command line. Large values, secrets, or environment-specific settings can become hard to read or leak into process listings. For those cases, environment variables or dedicated config files may be better.

You should also remember that shell quoting rules still apply. Values containing spaces or special characters need proper quoting, otherwise the shell can split or reinterpret them before Git ever sees them.

That is especially relevant in cross-platform scripts, where quoting behavior can differ between shells. A one-line override that works interactively can fail in automation if the value is not passed as a single argument.

Common Pitfalls

• Expecting -c to persist after the command finishes.
• Forgetting to quote values that contain spaces or special characters.
• Using git config in automation when a one-off -c override would be safer.
• Passing insecure temporary settings such as disabled SSL checks without understanding the risk.
• Assuming command-line overrides change repository data rather than only Git's behavior for that invocation.

Summary

• Use git -c key=value <command> for one-off configuration overrides.
• Supply multiple -c flags when a command needs several temporary settings.
• Prefer -c over editing config files when the change should not persist.
• Be careful with quoting and with security-sensitive temporary settings.
• Think of -c as a scoped override for one Git process, not a permanent configuration change.