Command Line Syntax for Viewing Global and Local Git Settings

You're knee-deep in a project, you type git status, and everything looks fine. But then a co-worker says, “Hey, your email is wrong in the commit history.” Suddenly you need to check your Git configuration. And honestly? Most developers I meet have no clue how the command line syntax for viewing global and local git settings actually works. They just hammer git config --list and hope for the best.

I’ve been using Git since before it was cool—back when people still argued about SVN versus CVS. Seriously, that’s over a decade of untangling messy configs, debugging merge tools, and explaining why the hell your user.name is set to “Bob” instead of “Robert”. So let me walk you through the exact command line syntax to view both global and local Git settings. No fluff, no jargon. Just the stuff that works.

And yes, we’re going to have fun with it. Because if you’ve ever accidentally committed with the wrong identity, you know the pain. Let’s fix that.

Understanding Git Configuration Levels

Before you start typing commands, you need to understand the three levels where Git settings live. Think of them like layers of an onion: system-wide (for every user on the machine), global (for your user account), and local (for a specific repository). The command line syntax for viewing each level is slightly different, and mixing them up is the number one cause of “why won’t my config change?” panic attacks.

System level is rare—usually managed by an admin. Global is where most of you live: your name, email, default editor, etc. Local is per-repo and overrides both. The hierarchy is simple: local beats global, global beats system. But the command line uses the same git config base, with flags to specify which level you're querying.

The Hierarchy That Rules Them All

Every time you run a git config command, Git checks local first, then global, then system. If you want to see only one layer, you need the right flag. Without a flag, git config defaults to local (if you're inside a repo) or global (if you're not). That little detail has tripped up more developers than I can count.

- System: git config --system — rarely touched, unless you're an admin. - Global: git config --global — your personal defaults. - Local: git config --local — project-specific overrides.

If you ever see a setting that doesn't match what you expect, the first thing to check is which layer is active. I've spent too many hours chasing a phantom proxy setting that turned out to be in a global config I forgot about. Don't be like me. Know your layers.

Why You Should Care About the Difference

Here’s the thing: when you run git config --list without flags, it shows all settings merged from all layers. That’s useful, but it doesn’t tell you where each value came from. You might see user.email=old@corporate.com and assume it’s global, when in reality it's a lingering local config from two years ago. The command line syntax for isolating layers is your friend.

- To see only global: git config --global --list - To see only local: git config --local --list - To see only system: git config --system --list

Memorize those three. They’re the backbone of every Git troubleshooting session. And for the love of version control, use them before you go blaming someone else’s config.

How to View Global Git Settings

Your global Git settings are stored in a file called ~/.gitconfig (or $HOME/.config/git/config on some modern setups). But you don’t need to hunt for that file—the command line does the heavy lifting. Let’s look at the exact syntax, plus a few tricks that save time.

The Classic Command: git config --global --list

Run this from anywhere—even outside a repository. It will print every key-value pair in your global config. Example output:

user.name=Jane Doe
user.email=jane@example.com
core.editor=nano
init.defaultbranch=main

That's it. But here's where most people stop. They think this is the only way. It's not. You can also query a single setting directly: git config --global user.name. That returns just the value for that key. I use this all the time when I want a quick check without scrolling through a list.

- List all global: git config --global --list - Get one global key: git config --global user.email - Check with show-origin: git config --global --list --show-origin

That last flag, --show-origin, is a hidden gem. It tells you the exact file path where each setting is stored. So if you have multiple global configs (yes, it's possible), you can trace the source. Absolute game-changer when you're debugging.

What If Your Global Config Is Insanely Long?

Look—some people (cough, me) have dozens of aliases, diff tools, and credential helpers in their global config. Scrolling through a wall of text is painful. That’s when you use grep or PowerShell Select-String to filter. The command line syntax becomes your search tool. For example:

git config --global --list | grep alias

This shows only aliases. Windows users: git config --global --list | findstr alias. I do this at least three times a week. It’s fast, it’s precise, and it beats reading a flat file.

Also, don’t forget that you can edit the raw file with git config --global --edit. That opens your default editor directly on ~/.gitconfig. If you prefer a GUI editor, set core.editor to your favorite. I have mine set to VS Code so I can visually scan sections. Whatever floats your boat.

How to View Local Git Settings

Local settings are specific to one repository. They live in .git/config inside the repo. This is where you override things like the remote URL, branch merge strategies, or even a different email for work projects. The command line syntax is almost identical to global, but without the --global flag.

Inside a Repository: git config --local --list

Navigate to your repo root and type:

git config --local --list

It will show everything that’s been set for that project. If you haven't set anything locally, the list might be empty or just show the remote origin. That’s normal. But here’s the critical part: local settings override global ones. So if you run git config user.name without the --local flag, and you’re inside a repo, Git will return the local value (if it exists). If not, it falls back to global.

- List all local: git config --local --list - Get one local key: git config --local user.email - Combine with show-origin: git config --local --list --show-origin

The --show-origin flag for local will point you to the exact .git/config file. That’s handy when you have multiple submodules or secondary worktrees.

Spotting Conflicts: Why Your Local Email Might Be Wrong

Ever committed with the wrong author and then blamed your global config? I have. But nine times out of ten, the culprit was a local setting I forgot about. Here’s a quick sanity check: run git config --list --show-origin (no flag preference). It shows every setting from all layers with its source file. Look for duplicate keys—like two user.email entries. The one with the local source wins.

I once spent an hour debugging a “permission denied” error on a remote push. Turned out the local config had a http.proxy set from an old corporate network. Running git config --local --list exposed it immediately. Don’t trust your memory. Trust the command line.

And if you want to remove a local setting? git config --local --unset key. But that’s a topic for another day. For now, just know that viewing is the first step to mastering.

Pro Tips and Common Pitfalls

You've got the basics. Now let me give you the hard-earned wisdom that separates “knows Git” from “lives Git.” These are the tricks I wish I had learned in year one, not year ten.

Using git config --list Without Flags Is a Trap

Yes, it shows everything. But it doesn’t show the source. I cannot count how many times I’ve seen newer developers run git config --list, see a value, and then get confused when changing the global config doesn’t take effect. Because the value was local. Always use --show-origin or query a specific layer. Make it a habit. Seriously.

- Trap: git config --list — ambiguous. - Fix: git config --list --show-origin — clear.

Also, be aware that git config --list can be slow in huge repos with many submodules. It scans every config file in the chain. For a lightning-fast check of a single key, use git config (which respects the hierarchy) or target a layer directly.

Viewing Global vs Local: A Quick Decision Tree

Here’s a mental model I use. Are you working on a single project and something seems off? Run local first. Is the issue persistent across all repositories? Go global. Is it affecting every user on the machine? That’s system-level—and you better have admin rights.

1. Inside the repo: git config --local --list 2. If that looks normal: git config --global --list 3. If still stuck: git config --system --list (or just ignore it)

I almost never touch system-level config. It’s like the third cousin nobody talks about. But it’s there if you need it.

The Hidden Power of git config --get and git config --get-all

Most people don’t know that git config can also return values by taking multiple keys from multiple files. For example, git config --get-all remote.origin.url will list all values for that key if it’s defined in multiple layers. That’s useful when you have a remote URL configured both globally and locally and want to see both. The command line syntax for viewing isn’t just about dumping lists—it’s about precise queries.

- Get single value (first found): git config --get user.name - Get all values: git config --get-all user.name

This is a lifesaver when you’re debugging scripts that rely on config values. I’ve caught more than one alias collision this way.