Git -c: Git Configuration vs Git Command Options for Customizing Git Commands

Use git -c when you want a one-time Git behavior change without touching any config file. Git documents -c <name>=<value> as a way to pass a config parameter to a single command [source: Git].

TLDR: git -c is temporary config. It affects one Git command, then disappears. Normal Git config is saved and reused. Command options, like git log --oneline, are direct instructions for that command. For example, a team running 60 CI jobs per day could use git -c advice.detachedHead=false checkout abc123 to quiet noisy logs without changing every runner config.

Think of Git as a picky coffee machine

Git has many knobs. Some are sticky. Some are not.

Git configuration is like setting your coffee machine to “strong coffee” every morning. It stays that way.

Git command options are like pressing “extra hot” just once. That cup changes. The machine does not.

git -c sits in the middle. It says, “Pretend this config value exists, but only for this command.” Then Git forgets it.

That is useful. Very useful. Especially when scripts are involved. It also saves you from the classic “why did my Git start acting weird?” debugging spiral. Honestly, it feels like Git hides tiny switches in sofa cushions sometimes.

The basic shape of `git -c`

The syntax is short:

git -c config.name=value command

Here are real examples:

git -c color.ui=always status
git -c core.editor=nano commit
git -c advice.detachedHead=false checkout abc123
git -c init.defaultBranch=main init

The key part is this:

-c comes right after git.
The config name comes next.
The Git command comes after that.
The setting applies only to that one command.

So this works:

git -c core.pager=cat log

But this does not mean your pager is now always cat. It only changes git log for that run.

Git configuration: the sticky stuff

Git config is saved in files. It lives at different levels.

System config: applies to every user on the machine.
Global config: applies to your user account.
Local config: applies to one repository.
Worktree config: applies to one worktree, if enabled.

You set config like this:

git config --global user.name "Mona"
git config --global user.email "mona@example.com"
git config --local core.autocrlf false

This is great for identity, defaults, aliases, merge tools, colors, pull behavior, and editor choices.

For example:

git config --global alias.lg "log --oneline --graph --decorate"

Now git lg works again and again. Nice.

But saved config can bite you. Expect to waste time on “works on my machine” bugs when one developer has a global setting that nobody else has. A single hidden pull.rebase=true can turn a calm morning into a tiny Git courtroom drama.

Command options: the direct orders

Command options are flags passed to a specific Git command.

Examples:

git log --oneline
git status --short
git commit --amend
git branch --all
git diff --staged

These are not config values. They are command instructions.

--oneline tells git log how to print output. --short tells git status to be brief. --amend tells git commit to edit the previous commit.

They do not live in config files. They do not stick. They run once.

That sounds similar to git -c. But the target is different.

git -c changes config for one run.
Command options change command behavior for one run.

That difference matters.

A simple comparison

Method	Example	Lasts how long?	Best for
Saved config	`git config --global color.ui auto`	Until changed	Personal defaults
`git -c`	`git -c color.ui=always status`	One command	Scripts and temporary tweaks
Command option	`git status --short`	One command	Changing that command directly

When should you use `git -c`?

Use git -c when you need Git to behave differently for one run, but you do not want to edit config files.

Good cases:

CI pipelines: keep builds clean and repeatable.
One-off scripts: avoid changing the user’s setup.
Temporary editors: use a different editor for one commit.
Noise control: suppress advice messages in automation.
Testing config: try a setting before saving it.

Example:

git -c core.editor=vim commit

This uses Vim for one commit. Your normal editor stays safe.

Another example:

git -c protocol.version=2 fetch

This runs git fetch with protocol version 2 for this command only.

When should you use saved Git config?

Use saved config for habits.

If you always want the same name, email, editor, branch name, or alias, save it.

git config --global user.name "Ravi"
git config --global user.email "ravi@example.com"
git config --global init.defaultBranch main

This is boring. That is good. Boring defaults are friendly defaults.

Saved config is also easier for humans. You type less. You think less. Your fingers stop filing complaints.

When should you use command options?

Use command options when Git already gives you a flag for the thing you want.

Want a compact log?

git log --oneline

Want ignored files too?

git status --ignored

Want to see staged changes?

git diff --staged

Do not force git -c into places where a normal option is clearer. Future you has enough problems.

Can you combine them?

Yes. And this is where it gets handy.

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

This says:

color.ui=always is temporary config.
log is the command.
--oneline and --decorate are command options.

Each part has a job. Nobody is stealing anybody’s lunch.

Precedence: who wins?

git -c usually wins over saved config for that command. If your global config says one thing, and git -c says another, the -c value is used for that run.

Example:

git config --global core.editor nano
git -c core.editor=code commit

That commit uses VS Code. Your global editor is still Nano after the command ends.

Command options also have strong control over their own command. If you run git log --oneline, Git prints the log in one-line style because you asked it to.

Common mistake: putting `-c` in the wrong place

This is wrong:

git status -c color.ui=always

Git will not treat that as global Git config for the command.

This is right:

git -c color.ui=always status

The -c option belongs to the main git program. Put it before the subcommand.

A practical rule

Ask one question:

“Am I changing a Git setting, or am I using a command feature?”

If it is a setting, use git config or git -c.
If it is a command feature, use a command option.
If it should last, use saved config.
If it should vanish, use git -c.

That is the clean mental model.

Use saved config for your normal Git life. Use command options for clear one-time command behavior. Use git -c when you need temporary config with zero cleanup. Your repo stays cleaner. Your scripts stay safer. Your future self sends a small thank-you note.